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Intellectual Property Rights 
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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in 
SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can 
be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) which 
are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by the Special Mobile Group (SMG) of the European 
Telecommunications Standards Institute (ETSI). 

This TS specifies the layer 3 procedures used on the Base Station System (BSS) to Mobile-services Switching Centre 
(MSC) interface for control of GSM services within the digital cellular telecommunications system. 

The contents of this TS is subject to continuing work within SMG and may change following formal SMG approval. 
Should SMG modify the contents of this TS, it will be re-released by SMG with an identifying change of release date and 
an increase in version number as follows: 

Version 6.x.y 

where: 

6 indicates GSM Release 1997 of Phase 2+ 

X the second digit is incremented for changes of substance, i.e. technical enhancements, corrections, updates, etc. 

y the third digit is incremented when editorial only changes have been incorporated in the specification; 
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Scope 



This Technical Specification (TS) specifies the layer 3 procedures used on the Base Station System (BSS) to Mobile- 
services Switching Centre (MSC) interface for control of GSM services. 

For the purposes of call control and mobility management, messages are not interpreted at the Base Station System (BSS) 
which acts as a relay function. These messages and procedures are documented in GSM 04.08, the only relevant issues 
covering these messages in this TS are those concerned with error conditions at the interface, and the headers that are 
required for the correct addressing of the messages. This is specified in more detail in GSM 08.06. 

The functional split between MSC and BSS is defined in GSM 08.02 and states that the BSS is responsible for local radio 
resource allocation and in order to support this the required procedures between BSS and MSC are defined in detail in 
this Technical Specification. 

GSM 08.02 also states that the BSS is responsible for the scheduling of all CCCH/BCCH messages and therefore some 
procedures for providing the BSS with the necessary information to be passed on these channels for individual calls (i.e. 
paging) are defined in this Technical Specification, but the scheduling is not discussed. 

This interface and consequently these layer 3 procedures are designed to support BSSs providing one or more cells. 

1.1 Normative references 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

For a specific reference, subsequent revisions do not apply. 

For a non-specific reference, the latest version applies. 

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[I] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and acronyms". 

[2] GSM 03.03: "Digital cellular telecommunications system (Phase 2+); Numbering, addressing and 

identification". 

[3] GSM 03.09: "Digital cellular telecommunications system (Phase 2+); Handover procedures". 

[4] GSM 03.34: "Digital cellular telecommunications system (Phase 2+); High Speed Circuit Switched 

Data (HSCSD)" 

[5] GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 

specification". 

[6] GSM 04.21: "Digital cellular telecommunications system (Phase 2+); Rate adaption on the Mobile 

Station - Base Station System (MS - BSS) interface". 

[7] GSM 05.01: "Digital cellular telecommunications system (Phase 2+); Physical layer on the radio 

path; General description". 

[8] GSM 05.02: "Digital cellular telecommunications system (Phase 2+); Multiplexing and multiple 

access on the radio path". 

[9] GSM 05.03: "Digital cellular telecommunications system (Phase 2+); Channel coding". 

[10] GSM 05.04: "Digital cellular telecommunications system (Phase 2+); Modulation". 

[I I] GSM 05.05: "Digital cellular telecommunications system (Phase 2+); Radio transmission and 
reception". 
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[12] GSM 05.08: "Digital cellular telecommunications system (Phase 2+); Radio subsystem link control". 

[13] GSM 05.90: "Digital cellular telecommunications system; GSM Electro Magnetic Compatibility 

(EMC) considerations" 

[14] GSM 05. 10: "Digital cellular telecommunications system (Phase 2+); Radio subsystem 

synchronization" . 

[15] GSM 08.02: "Digital cellular telecommunications system (Phase 2+); Base Station System - 

Mobile-services Switching Centre (BSS - MSC) interface; Interface principles". 

[16] GSM 08.06: "Digital cellular telecommunications system (Phase 2+); Signalling transport 

mechanism specification for the Base Station System - Mobile-services Switching Centre (BSS - 
MSC) interface". 

[17] GSM 08.20: "Digital cellular telecommunications system (Phase 2+); Rate adaption on the Base 

Station System - Mobile-services Switching Centre (BSS - MSC) interface". 

[18] GSM 12.00: "Digital cellular telecommunications system (Phase 2); Objectives and structure of 

Network Management (NM)". 

[19] GSM 12.01: "Digital cellular telecommunications system (Phase 2); Common aspects of GSM 

Network Management (NM)". 

[20] GSM 12.02: "Digital cellular telecommunications system (Phase 2); Subscriber, Mobile Equipment 

(ME) and services data administration". 

[21] GSM 12.03: "Digital cellular telecommunications system (Phase 2); Security management". 

[22] GSM 12.04: "Digital cellular telecommunications system (Phase 2); Performance data 

measurements". 

[23] GSM 12.05: "Digital cellular telecommunications system (Phase 2+); Subscriber related event and 

call data". 

[24] GSM 12.06: "Digital cellular telecommunications system (Phase 2); GSM Network change control". 

[25] GSM 12. 1 1: "Digital cellular telecommunications system (Phase 2); Maintenance of the Base Station 

System (BSS)". 

[26] GSM 12.20: "Digital cellular telecommunications system (Phase 2); Network Management (NM) 

procedures and messages". 

[27] GSM 12.21: "Digital cellular telecommunications system (Phase 2); Network Management (NM) 

procedures and message on the A-bis interface". 

[28] GSM 12.22: "Digital cellular telecommunications system (Phase 2); Interworking of GSM Network 

Management (NM) procedures and messages at the Base Station Controller (BSC)". 

1 .2 Abbreviations 

Abbreviations used in this TS are listed in GSM 01.04, see clause 5 for Vocabulary. 



Application to interface structures 



The underlying transport mechanism defined to carry signalling information between the BSS and the MSC is the Message 
Transfer Part (MTP), and the Signalling Connection Control Part (SCCP) of Signalling System No.7. 

The MTP and SCCP are used to support communication between the MSC and two conceptual entities within the BSS, 
these are: 

- the BSS Operation and Maintenance Application Part (BSSOMAP); 
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- the BSS Application Part (BSSAP). 

The BSS Application Part is split into two sub application parts, these are: 

- the BSS Management Application Part (BSSMAP); 
the Direct Transfer Application Part (DTAP). 

Distribution of messages between the two sub application parts is described in GSM 08.06. 

Figure 1 is a diagrammatical representation of these conceptual entities. It should be noted that this is not intended to 
imply a particular implementation and is only for the purposes of specifying the interface. 

Differentiation between BSSAP and BSSOMAP is by addressing mechanisms within the SCCP, using the subsystem 
number (see GSM 08.06). 

2.1 The BSS Operation and Maintenance Application Part 

If operation and maintenance messages are transferred by means of this interface then they shall use SCCP messages. The 
application protocol for the Operation and Maintenance Application Part is defined in the GSM 12 series Technical 
Specifications. The routing and addressing is provided by the SCCP and allows the MSC and the O&M centre to be 
addressed directly by the BSS using, for example, two E164 numbers. The operator may also use an X.25 connection for 
the transfer of O&M messages between the BSS and the OMC. This option is not further discussed in this Technical 
Specification. 

2.2 The Direct Transfer Application Part 

The Direct Transfer Application Part (DTAP) is used to transfer call control and mobility management messages between 
the MSC and the MS. The DTAP information in these messages is not interpreted by the BSS. GSM 08.06 contains more 
detail relating to the handling of DTAP messages at the BSS, the multiplexing of the messages onto the relevant signalling 
channels of the radio interface, and the use of the SCCP services. 

Messages received from the MS are identified as DTAP by the Protocol Discriminator Information Element as described 
in GSM 04.08, except for Initial Layer 3 messages (see subclause 3.1.16). The majority of radio interface messages are 
transferred across the BSS MSC interface by the DTAP, the exceptions being messages belonging to the Radio Resource 
(RR) management protocol. 

2.3 The BSS IVIanagement Application Part 

The BSSMAP supports all of the procedures between the MSC and the BSS that require interpretation and processing of 
information related to single calls, and resource management. 

Some of the BSSMAP procedures result in, or are triggered by. Radio Resource (RR) management messages defined in 
GSM 04.08. The BSSMAP procedures are described in clause 3. 

2.4 Handling of abnormal events related to the BSSAP Header 

The BSSAP header is specified in GSM 08.06. Several abnormal events may be detected by the receiver: 

use of a reserved value in the DLCI or discriminator; 

length octet with value zero; 

length octet with a value inconsistent with that indicated by the SCCP. 

In these cases the receiver may send a BSSMAP CONFUSION message as specified in subclause 3.2. 1. If so, depending 
on the error in the BSSAP header, the error pointer shall be set to one of the values reserved for the BSSAP header in 
subclause 3.2.2.32. 

Spare bits in the BSSAP header shall not be checked by the receiving entity. 
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The BSS Management Application Part 



3.1 



BSSIVIAP Procedures 



This subclause describes the procedures used in the BSS Management Application Part. There are the following main 
procedures: 



* 


Assignment 


figure 2 


# 


Blocking 


figure 10 and 25 


# 


Resource indication 


figure 12 


# 


Reset 


figure 11 


* 


Handover required indication 


figure 4 


* 


Handover resource allocation 


figure 5 


* 


Handover execution 


figure 3 


# 


Handover candidate enquiry 


figure 13 


* 


Release 


figures 6 and 7 


# 


Paging 


figure 15 


# 


Flow control 


figure 14 


* 


Classmark update 


figure 9 


* 


Cipher mode control 


figure 17 


* 


Trace invocation 




* 


Initial MS message 




* 


Queuing indication 




* 


Data link control SAP! not 






equal to 


figure 18 


# 


Reset circuit 




* 


PDSS1 flow control 




* 


Circuit re-selection 


figure 26 



These procedures are documented separately and are intended to be used by the operators/manufacturers to build up 
complete call sequences, in a flexible manner. Any sequences given where more than one procedure is shown 
concatenated are only for illustrative purposes. 

Each of the above procedures is qualified by either an asterisk (*) or a hash symbol (#). The hash symbol (#) denotes a 
global procedure which concerns a complete cell or BSS, or specific terrestrial circuits. The asterisk symbol (*) denotes 
a dedicated procedure which concerns a single dedicated radio resource on the radio interface, or in the case of a 
multislot configuration, all radio resources allocated to one mobile station. 

Messages used to support global procedures are sent using the connectionless services of the SCCP. 

Messages used to support dedicated procedures are sent using the connection oriented services of the SCCP, on the 
connection which has been set up to support that call or transaction. The establishment of SCCP connections is detailed in 
GSM 08.06. 

In the following description of each procedure it is explicitly stated whether the procedure is global or not, and hence the 
type of SCCP service used to support the procedure is defined. 

The handling of unknown terrestrial circuits is defined in subclause 3.1.19.6 and the procedures of subclause 3.1.19.6 take 
precedence over those of the rest of subclause 3.1. The procedures of the rest of subclause 3. 1 assume that the terrestrial 
circuit is known by the entity concerned. 



3.1.1 Assignment 



The purpose of the assignment procedure is to ensure that the correct dedicated radio resource(s) can be allocated or 
reallocated to a MS that requires it. However, the initial random access by the MS and "Immediate Assignment" to a 
DCCH is handled autonomously by the BSS without reference to the MSC. 



ETSI 



GSM 08.08 version 6.2.0 Release 1 997 13 TS 1 00 590 V6.2.0 (1 998-1 1 ) 

3.1 .1 .1 Successful Operation 

The initial conditions are assumed to be that the MS is in contact with the fixed infrastructure of a PLMN by means of one 
or more dedicated radio resources (and possibly a terrestrial resource), and that the MSC has analysed any relevant call 
control information and wishes to allocate or reallocate to the MS one or more radio resources (and possibly a terrestrial 
resource). 

The MSC is the entity that carries out the necessary analysis on the call control information received from the MS or fixed 
network customer. 

On the basis of this analysis a resource request is made to the appropriate BSS by sending it an ASSIGNMENT 
REQUEST message. This message contains details of the resource(s) required (for instance channel rate, channel type, 
data adaption, priority level etc.). If the requested resource(s) is/are for speech or data it also may indicate the terrestrial 
circuit that shall be used between the MSC and BSS. The description of the resource(s) can either be a complete 
specification, or give the BSS some freedom in the selection (for instance channel rate selection, speech version selection 
etc.). The ASSIGNMENT REQUEST message may also contain CLASSMARK information in case such information is 
available in the MSC, but assumed not to be available in the BSS. A full description of the message is given in subclause 
3.2.1.1. 

In this specification a "pool" is a group of circuits supporting the same channel types. 

The ASSIGNMENT REQUEST message is sent via the BSSMAP and is analysed within the BSS. Based on this analysis, 
which is not defined further in this Technical Specification, the BSS chooses the appropriate radio resource(s) and 
allocates the appropriate resources for transcoding, rate adaptation etc. On the terrestrial route connecting the BSS and 
MSC, certain circuits can be used for different combinations of bearer capabilities. This can be modelled by grouping the 
circuits into "pools" supporting the same channel types. The MSC holds this information as route data. If the MSC 
allocates an A interface circuit, it should only ever ask for resources from the BSS that it knows are not totally 
incompatible with the nominated circuit. The BSS will construct and send the appropriate radio assignment messages, if 
required (i.e., if the radio resource(s) has/have to be changed), as described in GSM 04.08 and start timer TIO. The 
ASSIGNMENT REQUEST message includes sufficient information to allow the BSS to construct the necessary layer 3 
radio messages. If the BSS allocates the A interface circuits, and such a circuit is needed, the BSS shall allocate a circuit. 

In the case where several circuit pools (groups of circuits supporting the same channel types) are available on the BSS 
MSC interface, the terrestrial circuit allocated by the MSC, if any, is chosen taking into account the circuit pool the circuit 
belongs to and the required channel type. 

The management of priority levels is implementation dependent, under operator control. 

If queuing is managed, new requests which cannot be served immediately are put in the queuing file according to the 
indicated priority levels. 

The priority levels and the preemption indicators may (singularly or in combination) be used to determine whether the 
assignment has to be performed unconditionally and immediately. This would lead to triggering of the preemption 
procedure which may then cause the forced release or forced handover of a lower priority connection if no free resource 
is immediately available. 

Whilst the process and the extent of the preemption procedure is operator dependent, the preemption indicators (refer to 
subclause 3.2.2.18.), if given in the ASSIGNMENT REQUEST, shall be treated on a per connection basis as follows: 

- the last received "Preemption Vulnerability indicator" and priority levels shall prevail. 

- if the "Preemption Capability indicator" bit is set to 1 , then this allocation request can trigger the running of the 
preemption procedure. 

- if the "Preemption Capability indicator" bit is set to 0, then this allocation request cannot trigger the preemption 
procedure. 

- if the "Preemption Vulnerability" bit is set to 1, then this connection is vulnerable and shall be included in the 
preemption process or procedure and as such may be subject to forced release or forced handover. 

- if the "Preemption Vulnerability" bit is set to 0, then this connection is not vulnerable to preemption and shall 
not be included in the preemption process and as such may not be subject to forced release or forced handover. 

- if no priority Information Element has been received, both "Preemption Capability" and "Preemption 
Vulnerability" bits shall be regarded as set to 0. 



ETSI 



GSM 08.08 version 6.2.0 Release 1 997 14 TS 1 00 590 V6.2.0 (1 998-1 1 ) 

The BSS shall ignore the classmark information included in the ASSIGNMENT REQUEST message if such information 
has already been received from the MS. 

The radio assignment procedure on the radio path is described in GSM 04.08. When the BSS is satisfied that the radio 
assignment procedure has been successfully accomplished (e.g. by receipt of a radio interface ASSIGNMENT 
COMPLETE message) it will stop timer TIO and return an ASSIGNMENT COMPLETE message over the BSS MSC 
interface. This will implicitly release the old dedicated radio resource(s) at the BSS. If an intra-BSS cell change has 
occurred during the assignment, the new cell identity is included in the ASSIGNMENT COMPLETE message and a 
HANDOVER PERFORMED message is not required. If the MSC gave the BSS some freedom in resource type selection, 
the choices made by the BSS are indicated in the ASSIGNMENT COMPLETE message. If the BSS has to allocate a 
circuit, the ASSIGNMENT COMPLETE message includes the identity of the circuit allocated by the BSS. 

When several circuit pools are present on the BSS MSC interface, and when the circuit is allocated by the MSC, the 
"circuit pool" information element shall be included in the ASSIGNMENT COMPLETE. The "circuit pool" field will 
indicate to the MSC the circuit pool of the CIC given in the ASSIGNMENT REQUEST message. 

If the assignment did not require a change of radio resource(s), and consequently no 04.08 radio assignment procedure had 
been invoked, then the ASSIGNMENT COMPLETE message shall be returned to the MSC as soon as the requested 
resources have been allocated within the BSS. 

If the assignment requires a change of terrestrial circuit or in the case of assignment for signalling the release of a 
previously used terrestrial circuit, the change or release shall be performed before the ASSIGNMENT COMPLETE 
message is sent and the BSS shall consider that the old terrestrial circuit is idle. 

After the completion of the assignment procedure, until the connection is released or the MSC performs a new assignment, 
any dedicated resource assigned to the mobile station, e.g. at internal handover, must be in accordance with the 
description in the ASSIGNMENT REQUEST message. 

In the case of voice group calls the MSC may inform the BSS to which voice group call an MS belongs to and whether the 
MS is a talker or listener in the voice group call, the BSS may decide to allocate and assign a voice group call channel 
relating to the group call reference. If the BSS allocates a voice group call channel it will send the ASSIGNMENT 
COMPLETE message and then immediately afterwards send a CLEAR REQUEST cause "Joined group call channel". 

3.1.1.2 Assignment Failure 

The following failure conditions may occur: 

The BSS may not be able to use the terrestrial resource that the MSC has indicated in which case an ASSIGNMENT 
FAILURE message will be returned to the MSC with the cause set to "requested terrestrial resource unavailable". 

If the requested channel type or resource (e.g. channel rate, speech version, etc.) indicated in the ASSIGNMENT 
REQUEST message is not available in the BSS, then an ASSIGNMENT FAILURE message shall be returned to the MSC. 
The appropriate failure cause will be included in the message (Cause value; "requested transcoding/rate adaptation 
unavailable" or "requested speech version unavailable"). 

If, on reception by the BSS of an ASSIGNMENT REQUEST message allocating a circuit, the circuit pool implied by the 
CIC information element is incompatible with the channel type indicated (that is, the pool does not support any of the 
radio resources indicated by the channel type) an ASSIGNMENT FAILURE shall be returned to the MSC with the failure 
cause set to "circuit pool mismatch". 

If, on reception by the BSS of an ASSIGNMENT REQUEST message allocating a circuit, the circuit pool implied by the 
CIC is compatible with the channel type indicated (that is, the pool supports at least one of the radio resource types 
indicated by the channel type), but the BSS still wishes to change the circuit pool, it sends an ASSIGNMENT FAILURE 
with the cause "switch circuit pool" and the "circuit pool list" information element. 

The "circuit pool" information element, when present in the ASSIGNMENT FAILURE, indicates to the MSC which 
circuit pool the CIC indicated in the ASSIGNMENT REQUEST belongs to. This can be used by the MSC to correct its 
tables (CIC/circuit pool). The "circuit pool list" information element, when present in the ASSIGNMENT FAILURE, is 
used when the BSS wishes to indicate to the MSC its preferred circuit pools. The circuit pools in the "circuit pool list" 
information element shall be given in order of preference. In the case of an ASSIGNMENT FAILURE with the cause 
"circuit pool mismatch", the MSC may decide to block the circuit and to send an O & M notification. 
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The BSS may not receive a radio interface ASSIGNMENT COMPLETE message from the MS in which case the timer 
TIO will expire. In this case an ASSIGNMENT FAILURE message is returned to the MSC and the assignment procedure 
is terminated (cause value: radio interface message failure). 

If the cell for which the assignment is intended is congested, the BSS may indicate an impending directed retry attempt by 
sending ASSIGNMENT FAILURE (Cause value: directed retry). 

If the radio channel assignment fails for any other reason then an ASSIGNMENT FAILURE message will be returned to 
the MSC, the procedure will terminate, and the associated references concerning the old dedicated resource(s) should be 
maintained until explicitly released by the MSC. It should be noted that if the MS fails to assign after receiving a radio 
interface ASSIGNMENT COMMAND and returns to the old channels as detailed in GSM 04.08, then the radio interface 
ASSIGNMENT FAILURE message received from the MS will cause an ASSIGNMENT FAILURE message to be 
returned to the MSC (cause value: "Radio interface failure, reversion to old channel"). 

Other possible Cause values which may be returned with the ASSIGNMENT FAILURE message are: "equipment failure", 
"no radio resource available", "O&M intervention". If an unrecognised cause value is received, the Class of the cause 
value should be used to determine the MSC's action. 

In the case where the MSC has attempted to assign a terrestrial circuit and an ASSIGNMENT FAILURE message has 
been returned then both the MSC and the BSS shall consider that the terrestrial circuit is idle (except as described below 
in subclause 3.1.L3) and therefore no explicit clearing sequence is needed. 

The MSC may not be able to use the terrestrial resource that the BSS has indicated. In this case, the procedure is 
nevertheless considered terminated successfully, and it is up to the MSC to correct the situation, e.g., by a circuit re- 
selection procedure. 

All messages concerned with an assignment are sent using the connection oriented mode of the SCCP. 

3.1 .1 .3 Abnormal Conditions 

If the BSS receives an ASSIGNMENT REQUEST message calling up a terrestrial circuit that is already assigned to 
another call then an ASSIGNMENT FAILURE message will be returned with a Cause value of: "terrestrial circuit already 
allocated" and no action will be taken on the radio interface. 

If the BSS receives an ASSIGNMENT REQUEST message allocating a terrestrial circuit which has been blocked by a 
global block message, then an ASSIGNMENT FAILURE message shall be sent (Cause value: "requested terrestrial 
resource unavailable"). A single global BLOCK message (not repeated and not guarded by timer Tl) shall be sent for that 
concerned terrestrial circuit. 

If an external handover becomes necessary during an assignment, for reasons of radio conditions or congestion (directed 
retry), the BSS may initiate the handover whilst the assignment is in progress. In this situation, if a HANDOVER 
COMMAND is received by the BSS, it must not be ignored. 

3.1.2 Blocking and Unblocking 

As described in subclause 3.1.1 the assignment procedure depends upon one side, the MSC or the BSS, choosingthe 
terrestrial resource to be used. If the entity on one side puts out of service any terrestrial circuit, it needs to inform the 
peer entity on the other side of the interface. This is performed by using a simple blocking/unblocking procedure. The 
block messages used to support this procedure are sent as global messages (i.e. using the SCCP connectionless mode). 
Each message refers to one or more terrestrial circuits accessed through the BSS MSC interface. The circuit is identified 
by its Circuit Identity Code. 

The support of blocking/unblocking procedures is dependent on which side allocates the circuits. 

A circuit is said to be « locally blocked » on a given side if it has been put out of service for a local reason, and to be 
« remotely blocked » if a BLOCK message about this circuit has been received from the peer entity. 

3.1.2.1 Successful Operation 

The procedure operates as follows: 

Initial conditions are assumed to be that all circuits are remotely unblocked. 
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An entity may locally block a terrestrial circuit because: 

- Operation and Maintenance intervention makes the circuit unavailable for use (Cause value: "O and M 
intervention"). 

- An equipment failure makes the circuit unavailable (Cause value: "equipment failure"). 

- Radio resource is not accessible from the terrestrial circuit (Cause value: "no radio resource available"). 

When and if the party that does not allocate the circuits (the Circuit Slave) decides to locally block a terrestrial circuit, it 
shall immediately mark that terrestrial circuit as "blocked" (to stop any future allocation of that terrestrial circuit) and 
shall then send a block message to the peer entity allocating the circuits (the Circuit Master) and start timer Tl (T20, T21, 
T22). 

The BLOCK message contains the Circuit Identity Code indicating the terrestrial circuit that is to be remotely blocked and 
a Cause Information Element indicating the reason for blocking. Typical Cause values are: "no radio resources available", 
"O and M intervention", "equipment failure". 

A BLOCK message in the MSC to BSS direction may also contain an indication that the connection using the circuit, if 
any, must be released ; in such a case the circuit master shall check if the circuit is in use and shall release the connection 
that uses it. 

Note : This allows the MSC to simultaneously block the circuit and to release the connection using the circuit, if any, and 
then to prevent use of the circuit by the BSS between connection release and blocking. 

If the CIRCUIT GROUP BLOCK message is applied by the circuit slave the circuits to be remotely blocked are indicated 
in the status field of the Circuit Identity Code List (3.2.2.31). 

Receipt of a block message (BLOCK or CIRCUIT GROUP BLOCK) at the circuit master from the circuit slave will 
indicate to the circuit master that the identified circuits are unavailable for reselection. If a call is in progress on any of 
the identified terrestrial circuits then it will be unaffected by this procedure unless explicitly requested, the circuits will 
however be "camp on blocked". Such circuits shall be remotely blocked as soon as that call is no longer in progress, or 
active. 

On receipt of a BLOCK message asking for the release of the connection using the circuit if any, and if the BSS detects 
that there exists a connection using the indicated circuit, the BSS shall attempt to release that connection, e.g., by sending a 
CLEAR REQUEST message on the corresponding SCCP connection. As specified in subclause 3.1.17, if the SCCP 
connection has been lost, the BSS will detect it when attempting to release the connection and the whole connection is 
released as a consequence. 

An appropriate blocking acknowledge message (BLOCKING ACKNOWLEDGE or CIRCUIT GROUP BLOCKING 
ACKNOWLEDGE) will be returned to the circuit slave by the circuit master to acknowledge receipt of the block 
message and to indicate that any necessary action has been taken. 

The CIRCUIT GROUP BLOCKING ACKNOWLEDGEMENT message is accepted as the appropriate acknowledgement 
only if the indicated Circuit Identity Code and the returned Range field of the Circuit Identity Code List match the 
corresponding parameter values of the respective initiating message. Otherwise the message is considered as not 
expected. 

On receipt of the blocking acknowledge the circuit slave shall stop timer Tl (T20, T21, T22). 

The resource involved will be assumed to be remotely blocked by the circuit master until either an unblock (UNBLOCK 
or CIRCUIT GROUP UNBLOCK) or RESET message is received relevant to that resource. 

If the circuit slave wishes to unblock a blocked circuit and return it to service then it shall immediately mark the circuit as 
"locally unblocked" and then send an unblock message, and start timer Tl (T20, T21, T22). 

If an unblock message (UNBLOCK or CIRCUIT GROUP UNBLOCK) is received at the circuit master for a blocked 
resource then the resource will be marked as not remotely blocked and an unblocking acknowledge message 
(UNBLOCKING ACKNOWLEDGE or CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE) will be returned to the 
circuit slave. The circuit slave shall stop timer Tl (T20, T21, T22) on receipt of this unblocking acknowledge. 

The CIRCUIT GROUP UNBLOCKING ACKNOWLEDGEMENT message is accepted as the appropriate 
acknowledgement only if the indicated Circuit Identity Code and the returned Range field of the Circuit Identity Code List 
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match the corresponding parameter values of the respective initiating message. Otherwise the message is considered as 
not expected. 

Figure 10 shows an overview of the blocking procedure in the case the circuit slave is the BSS. 

NOTE: Timer Tl is used to supervise a single circuit block/unblock procedure on the BSS side, whilst T20 is used 
to supervise the circuit group block/unblock procedure on the BSS side, timer T21 is used to supervise a 
single circuit block/unblock procedure on the MSC side, and T22 is used to supervise the circuit group 
block/unblock procedure on the MSC side. 

3.1.2.2 Abnormal Conditions 

If a blocking acknowledge message is not received for a block message within Tl (T20, T21, T22) seconds then the block 
message will be repeated. If this occurs a second time the circuits will be kept marked as locally blocked, and the 
situation must then be resolved internally within the circuit slave or by O&M procedures. 

If an unblocking acknowledge message is not received for an unblock message before expiry of timer T1(T20, T21, T22) 
then the unblock message will be repeated. If this occurs a second time, this situation may be reflected to the O&M, which 
shall resolve the possible conflict. The unblock message is repeated at most one time. Whatever the outcome of possible 
repetitions, the concerned circuits remain locally "unblocked". 

If the MSC allocates the circuits, and an ASSIGNMENT REQUEST or HANDOVER REQUEST message is received by 
the BSS allocating a circuit which is marked at the BSS as blocked then an ASSIGNMENT FAILURE message or a 
HANDOVER FAILURE message (respectively) followed by a BLOCK message shall be sent to the MSC. 

If the BSS allocates the circuits, and an ASSIGNMENT COMPLETE, HANDOVER REQUEST ACKNOWLEDGE or 
CHANGE CIRCUIT ACKNOWLEDGE message is received by the MSC allocating a circuit which is marked at the MSC 
as blocked, it is up to the MSC how to correct the situation, e.g., by performing a circuit re-selection procedure and 
sending a BLOCK message. 

3.1 .2.2.1 Applying to the Single Circuit Block Procedure 

i) If a BLOCK message is received for a circuit already remotely blocked, a BLOCKING ACKNOWLEDGE 
message will be sent. 

ii) If an UNBLOCK message is received for a remotely unblocked circuit, an UNBLOCKING ACKNOWLEDGE 
message will be sent. 

iii) If a BLOCKING ACKNOWLEDGE message, which is not expected as an acknowledgement for a BLOCK 
message, is received: 

a) relating to a circuit which is locally blocked, the BLOCKING ACKNOWLEDGE message is discarded. 

b) relating to a circuit, which is not locally blocked, then an UNBLOCK message will be sent. 

iv) If an UNBLOCKING ACKNOWLEDGE message, which is not expected as an acknowledgement for an 
UNBLOCK message, is received: 

a) relating to a circuit which is not locally blocked, the received UNBLOCKING ACKNOWLEDGE message is 
discarded. 

b) relating to a circuit, which is locally blocked, then a BLOCK message will be sent. 

3.1 .2.2.2 Applying to the Circuit Group Block Procedure 

v) If a CIRCUIT GROUP BLOCK message is received relating to remotely blocked circuits then blocking 

acknowledgement indications for those circuits are given in the status field of the corresponding CIRCUIT GROUP 
BLOCKING ACKNOWLEDGE message which will be sent in response. 

vi) If a CIRCUIT GROUP UNBLOCK message is received relating to circuits which are not remotely blocked then 
unblocking acknowledgement indications for those circuits are given in the status field of the corresponding 
CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE message which will be sent in response. 
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vii) When the circuit master upon receipt of a CIRCUIT GROUP BLOCK (UNBLOCK) message is not able to give 
an appropriate blocking (unblocking) acknowledgement indication for each Circuit Identification Code (e.g. 
because that/those Circuit Identification Code(s) is (are) not allocated to any circuit at the receiving entity) for 
which a block (unblock) indication is given in the status field of the received CIRCUIT GROUP BLOCK 
(UNBLOCK) message, then no blocking (unblocking) acknowledgement relating to that/those Circuit Identification 
Code(s) will be given in the status field of the corresponding CIRCUIT GROUP BLOCKING (UNBLOCKING) 
ACKNOWLEDGE message which will be sent in response. 

viii) If a CIRCUIT GROUP BLOCKING ACKNOWLEDGE message in response to a CIRCUIT GROUP BLOCK 
message is received by the circuit slave containing in the status field no blocking acknowledgement for circuits 
which are to be blocked due to the previously sent CIRCUIT GROUP BLOCK message, then the CIRCUIT 
GROUP BLOCK message will be repeated for the circuit(s) concerned. 

If this occurs a second time the concerned circuit(s) will be kept marked as locally blocked, and the situation must 
then be resolved internally within the circuit slave or by O&M procedures. 

ix) The same rule applies to the Circuit Group Unblocking procedure with the only difference that the involved 
terrestrial circuits are kept marked as locally "not blocked". 

x) If a CIRCUIT GROUP BLOCKING ACKNOWLEDGE message in response to a CIRCUIT GROUP BLOCK 
message is received by the circuit slave containing in the status field blocking acknowledgement indications for 
circuits which are not to be blocked, then an appropriate unblock message will be sent for the circuit(s) concerned. 

xi) If a CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE message in response to a CIRCUIT GROUP 

UNBLOCK message is received by the circuit slave containing in the status field unblocking acknowledgement 
indications for circuits which have to remain marked as locally blocked then an appropriate block message will be 
sent for the circuit(s) concerned. 

xii) If a CIRCUIT GROUP BLOCKING ACKNOWLEDGE message which is not expected and not accepted as an 
acknowledgement for a CIRCUIT GROUP BLOCK message is received: 

a) relating to circuits which all are in the status locally blocked, then the received CIRCUIT GROUP BLOCKING 
ACKNOWLEDGE message will be discarded; 

b) related to circuits part or all of which are not in the status locally blocked then an appropriate unblock message 
will be sent for the relevant circuit(s). 

xiii) If a CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE message which is not expected and not accepted as 
an acknowledgement for a CIRCUIT GROUP UNBLOCK message is received: 

a) relating to circuits none of which is in the status locally blocked, then the received CIRCUIT GROUP 
UNBLOCKING ACKNOWLEDGE message will be discarded; 

b) related to circuits part or all of which are locally blocked then an appropriate block message will be sent for 
the relevant circuit(s). 

3.1.3 Resource Indication 

The purpose of the resource indication procedure is: 
To inform the MSC of the amount 

- of radio resource that is spare at the BSS and available for traffic carrying purposes; and 

- of the total amount of the accessible radio resource (i.e. available for service or currently assigned). 

This cannot easily be derived from the traffic that the MSC is carrying. The MSC may take these pieces of 
information into account for the external handover decision. 

3.1.3.1 Successful Operation 

The procedure relates to a single cell. 
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The MSC determines the resource information (i.e. the resource available information and optionally the total resource 
accessible information) and the manner in which the BSS transfers this resource information to the MSC by sending a 
RESOURCE REQUEST message to the BSS. This message shall contain a Resource Indication Method Information 
Element which can be set to one of the following values: 

i) (Spontaneous resource information expected): The BSS shall send the first RESOURCE INDICATION message 
without any resource information to the MSC immediately as an acknowledgement to the RESOURCE REQUEST 
message and then any further RESOURCE INDICATION messages spontaneously every time conditions, defined 
by O&M, are met in the BSS for the considered cell (e.g. traffic thresholds, or time interval between two 
messages). If the O&M conditions for sending RESOURCE INDICATION messages are met, the BSS may use the 
Periodicity IE received in the RESOURCE REQUEST message to determine the time interval between indications, 
except that, if the MSC sets the Periodicity IE to zero then the BSS shall ignore the Periodicity IE. The BSS stays 
in this mode until the receipt of a new RESOURCE REQUEST message for the same cell, or a reset occurs; 

ii) (One single resource information expected): The BSS shall return a single RESOURCE INDICATION message 
with some resource information immediately. If the RESOURCE REQUEST message does not contain an Extended 
Resource indicator IE the BSS shall then cease any resource information transfer related to the cell until the receipt 
of either a new RESOURCE REQUEST message or a reset. If the RESOURCE REQUEST message contains an 
Extended Resource Indicator IE the BSS shall obey the 'Subsequent Mode' field; 

iii) (Periodic resource information expected): The BSS shall return a RESOURCE INDICATION message with some 
resource information immediately, and then periodically, with a period set by MSC*, until the receipt of either a 
new RESOURCE REQUEST message for the same cell or a reset. 

* (The period shall equal the value of the periodicity parameter times 100 ms. If the value of the periodicity 

parameter is zero, then the message should be treated as one containing an incorrect value according to subclause 
3.1.19.4, case 2.) 

iv) (No resource information expected): The BSS shall immediately return a single RESOURCE INDICATION 
message without any resource information as an acknowledgement to the RESOURCE REQUEST message and 
then the BSS to MSC transfer of resource information related to the cell is disabled until the receipt of either a new 
RESOURCE REQUEST message for the same cell or a reset. 

The default mode is iv); after a reset, this mode is set for all the cells of a BSS. 

The transfer of resource information related to a given cell from the BSS to the MSC occurs when the Resource Indication 
Method Information Element is set to one of the values i) to iii) in the BSS. The BSS sends RESOURCE INDICATION 
messages to the MSC, under the conditions explained above. The RESOURCE INDICATION message shall contain the 
Resource Indication Method Information Element with the same value as it was requested by the MSC, i.e. the BSS is not 
allowed to select a method different from the one requested by the MSC. 

Furthermore, the RESOURCE INDICATION message may contain the Resource Available IE and the Total Resource 
Accessible IE dependent on the selected method and, in case of the Total Resource Accessible IE, also dependent on the 
request from the MSC. If the RESOURCE INDICATION message is just taken as a simple acknowledgement as stated in 
method i) and iv), the Total Resource Accessible IE shall not be returned independent of whether it was requested by the 
MSC or not. 

For each idle channel the level of interference will be averaged over a period of Intave. (Intave is a parameter set by 
O&M command on a per cell basis). This averaging will be performed immediately before the transmission of the 
RESOURCE INDICATION message. The result of this averaging will be used to classify the average interference level 
on the idle channels into five interference bands. 

The Resource Available Information Element contains two pieces of information for each of the five interference bands: 

The number of half rate TChs available in that band. 

The number of full rate TChs available in that band. 
The levels of the five bands are defined by O&M. 
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3.1.4 Reset 

3.1.4.1 Global Reset Procedure 

The purpose of the reset procedure is to initiaUse the BSS and MSC in the event of a failure. The procedure is a global 
procedure applying to a whole BSS, and therefore all messages relating to the reset procedure are sent as global messages 
using the connectionless mode of the SCCP. 

If only a limited part of the MSC or BSS has suffered a failure then clearing procedures can be used to clear only those 
affected calls. 

3.1.4.1.1 Reset at the BSS 

In the event of a failure at the BSS which has resulted in the loss of transaction reference information, a RESET message 
is sent to the MSC. This message is used by the MSC to release affected calls and erase all affected references, and to put 
all circuits into the idle state. 

After a guard period of T2 seconds a RESET ACKNOWLEDGE message is returned to the BSS indicating that all 
references have been cleared. 

After the sending of the RESET to the MSC a BSS that does not allocate the circuits shall initiate blocking procedures 
(Block or Circuit group block procedures) for all circuits that are locally blocked on the BSS side, the MSC shall respond 
as specified in subclause 3.1.2. The sending of block messages shall be done without waiting for the acknowledgement to 
the RESET message. 

Upon receipt of a RESET message from the BSS an MSC that does not allocate the circuits shall send block messages 
(BLOCK or CIRCUIT GROUP BLOCK) for all circuits that are locally blocked on the MSC side, the BSS shall respond 
to these with blocking acknowledge messages as described in subclause 3.1.2. 

3.1.4.1.2 Reset at the MSC 

In the event of a failure at the MSC which has resulted in the loss of transaction reference information, a RESET message 
is sent to the BSS. This message is used by the BSS to release affected calls and erase all affected references. 

After the sending of the RESET to the BSS, an MSC that does not allocate the circuits shall initiate blocking procedures 
(Block or Circuit group block procedures) for all circuits that are locally blocked on the MSC side, the BSS shall respond 
as specified in subclause 3.L2. The sending of block messages shall be done without waiting for the acknowledgement to 
the RESET message. 

Upon receipt of a RESET message from the MSC a BSS that does not allocate the circuits shall send block messages 
(BLOCK or CIRCUIT GROUP BLOCK) for all circuits that were previously locally blocked on the BSS side, the MSC 
shall respond to these with blocking acknowledge messages as described in subclause 3.1.2. 

After a guard period of T13 seconds a RESET ACKNOWLEDGE message is returned to the MSC, indicating that all MSs 
which were involved in a call are no longer transmitting and that all references at the BSS have been cleared. 

3.1 .4.1 .3 Abnormal Conditions 

3.1 .4.1 .3.1 Abnormal Condition at the BSS 

If the BSS sends a RESET message to the MSC and receives no RESET ACKNOWLEDGE message within a period T4 
then it shall repeat the entire reset procedure. The sending of the RESET message is repeated a maximum of "n" times 
where n is an operator matter. After the n-th unsuccessful repetition the procedure is stopped and the maintenance system 
is informed. 

3.1 .4.1 .3.2 Abnormal Condition at the MSC 

If the MSC sends a RESET message to the BSS and receives no RESET ACKNOWLEDGE message within a period T16 
then it shall repeat the entire reset procedure. The sending of the RESET message is repeated a maximum of "n" times 
where n is an operator matter. After the n unsuccessful repetition the procedure is stopped and the maintenance system is 
informed. 
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3.1.4.2 Reset Circuit 

The purpose of the reset circuit procedure is to restore the information in MSC/BSS in the case of a failure which has 
affected only a small part of the equipment (e.g. abnormal SCCP connection release). 

3.1 .4.2.1 Reset Circuit at the BSS 

If a circuit has to be put to idle at the BSS due to an abnormal SCCP-connection release, a RESET CIRCUIT message 
will be sent to the MSC. When the MSC receives this message, it clears the possible call and puts the circuit, if known, to 
the idle state. If the circuit is known, a RESET CIRCUIT ACKNOWLEDGE message is returned to the BSS. If circuit 
allocation is done by the BSS and if the circuit is locally blocked at the MSC a BLOCK message shall be returned to the 
BSS. The BSS shall then respond with a BLOCKING ACKNOWLEDGE message, as described in subclause 3.1.2. If the 
circuit is unknown in the MSC, an UNEQUIPPED CIRCUIT message is returned to the BSS. 

Timer T19 is used at the BSS to supervise the reset circuit procedure. If the timer elapses before a response (RESET, 
RESET CIRCUIT ACKNOWLEDGE or UNEQUIPPED CIRCUIT) is returned to the BSS, the procedure is repeated. 

3. 1 .4.2.2 Reset Circuit at the IVISC 

If a circuit has to be put to idle at the MSC due to an abnormal SCCP-connection release, a RESET CIRCUIT message 
will be sent to the BSS. When the BSS receives a RESET CIRCUIT message, it shall respond with a RESET CIRCUIT 
ACKNOWLEDGE message in case the circuit can be put to idle. If circuit allocation is done by the MSC and if the circuit 
is locally blocked at the BSS a BLOCK message shall be returned to the MSC. The MSC shall then respond with a 
BLOCKING ACKNOWLEDGE message, as described in subclause 3.1.2. If the circuit is unknown at the BSS, the BSS 
shall return an UNEQUIPPED CIRCUIT message to the MSC. 

Timer T12 is used at the MSC to supervise the reset circuit procedure. If the Timer elapses before a response (RESET, 
RESET CIRCUIT ACKNOWLEDGE, UNEQUIPPED CIRCUIT or BLOCK) the reset circuit procedure is repeated. 

3.1 .4.2.3 Abnormal conditions 

If a RESET message is received after sending of a RESET CIRCUIT message and before receipt of the corresponding 
response the respective reset circuit procedure is stopped, i.e. reception of the corresponding RESET CIRCUIT 
ACKNOWLEDGE message is not required and no repetition is necessary. 

If a RESET CIRCUIT message is received immediately after a RESET CIRCUIT message has been sent for the same 
circuit, the corresponding acknowledgement messages are returned. 

The sending of the RESET CIRCUIT message is repeated a maximum of "n" times where n is an operator matter. After the 
n-th unsuccessful repetition the procedure is stopped and the maintenance system is informed. 

3.1.5 External Handover 

The details of the radio information as far as handover is concerned are given in GSM 04.08. The relevant network 
information is given in GSM 03.09. 
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Using this protocol the BSS should support handover transitions to and from any combinations of the following: 



Channel 



SDCCH 

Full Rate TCH 

Half Rate TCH 

Multiple Full Rate TCHs 



In this specification three procedures are defined which can be used for handover. They are; 

Handover Required Indication; 

Handover Resource Allocation; 

Handover Execution. 

(Figure 16 shows an example of a complete handover procedure) 

For any HANDOVER REQUIRED message at most one HANDOVER COMMAND message may be sent. 

In the case of inter-MSC handover the term "the MSC" in this subclause is taken to mean the relevant MSC in the handover 
operation. 

The handover procedures are specified in the following subclauses. 

All messages concerned with handover, with the exception of HANDOVER CANDIDATE ENQUIRE and HANDOVER 
CANDIDATE RESPONSE messages, are sent using the connection oriented mode of the SCCP. 

3.1.5.1 Handover Required Indication 

The handover required indication procedure allows a BSS to request that a handover is to be carried out for a particular 
MS, currently allocated one or more dedicated resources. This is done by generating a HANDOVER REQUIRED 
message and sending it from the BSS to the MSC. If so required by the BSS the MSC informs the BSS if the handover 
cannot be carried out. This is done by a HANDOVER REQUIRED REJECT message. The HANDOVER REQUIRED 
message is sent using the BSSAP SCCP connection already set up for that transaction. As part of the BSS's functions, the 
BSS continually monitors all radio information, and compares it with parameters such that if the transmission quality of a 
given parameter (or set of parameters) passes a predetermined threshold (set by O&M) then a HANDOVER REQUIRED 
message is generated and sent to the MSC. 

3.1 .5.1 .1 Generation of the HANDOVER REQUIRED message 

Generation of the HANDOVER REQUIRED message can be for the following reasons: 

- The BSS has detected that a radio reason exists for a handover to occur. 

- The MSC has initiated a handover candidate enquiry procedure, and this MS is currently a candidate. 

- A cell change is required at call setup due to congestion, e.g. directed retry. 
The HANDOVER REQUIRED message contains the following information elements: 

- Message Type; 

- Cause; 

- Cell Identifier List (preferred). 

It should also contain the information elements: "Current channel type 1", "old BSS to new BSS information" and, in case 
the current channel mode is speech, "Speech version (used)". 

The "Old BSS to New BSS information" is used to pass Field Elements from the old BSS to the new BSS. The 
information in the "Old BSS to New BSS information" is transparent for the MSC. When the "Old BSS to New BSS 
information" is present in the HANDOVER REQUIRED message the MSC shall pass it unchanged to any BSS associated 
to "Cell Identifier List (preferred)" when initiating the Handover resource allocation procedure. The old BSS must ensure 
that the information contained in the "Old BSS to New BSS information" information element is valid for all cells in the 
"Cell Identifier List (preferred)". 
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Sec. 3.2.1.9. gives coding details of the above message. 

The "Cause" field indicates the reason for the HANDOVER REQUIRED message e.g. "uplink quality poor" or "response 
to MSC invocation" in the case of traffic reasons indicated by the MSC. 

The Cause value sent should be an indication which can be taken into account at the target BSS in future handover 
decision processes, e.g. to reduce oscillations between BSSs due to the fact that some information (on which the old BSS 
decided to initiate the handover) is not available at the target BSS (e.g. distance, traffic...). 

If present the "Response Request" Information Element indicates, that the BSS requires an indication if the HANDOVER 
REQUIRED message does not result in a HANDOVER COMMAND message. 

If the BSS wants to change the CIC due to a channel change, the BSS sends a HANDOVER REQUIRED message with the 
cause "switch circuit pool" and the "circuit pool list" information element. The "circuit pool list" information element will 
allow the BSS to indicate to the MSC from which circuit pool or pools the new CIC should be chosen. 

The "Cell Identifier List (preferred)" shall identify "n" preferred cells. The identified cells are given in order of 
preference. The algorithm by which the BSS produces this list is Operator dependent and is not addressed in this 
Technical Specification. The "n" number of preferred cells is a parameter set by O&M and shall range from 1 to 16. If "n" 
number of cells cannot be identified, then only as many as are available shall be encoded and sent (as specified in section 

3.2.2.27). 

It is mandatory for the BSS to be able to produce this "Cell Identifier List (preferred)". The sending of this list is 
controlled by the O&M parameter "n". It is mandatory for the MSC to be able to receive and interpret this Information 
Element. 

The BSS may recommend to the MSC to allow queuing or not in the handover resource allocation procedure by indication 
in the "Queuing indicator" information element within the HANDOVER REQUIRED message. 

The old BSS may inform the new BSS of the presently configured channel in the Current Channel Type 1 information 
element and in the Current Channel type 2 Field Element. The information contained may be used by the new BSS (e.g. 
when building the radio interface HANDOVER COMMAND message). Where discrepancies occur between the Current 
Channel Type 1 and the Current Channel Type 2 then the information in the Current Channel Type 2 shall take precedence 
if understood by the new BSS. 

If, for this mobile station, the old BSS has received a Gb interface SUSPEND ACK PDU, then the old BSS shall include 
the GPRS Suspend information field in the Old BSS to New BSS IE in the HANDOVER REQUIRED message. 

If the old BSS received a GPRS Suspend information field in the Old BSS to New BSS IE in any preceding HANDOVER 
REQUEST message received by the old BSS, then, the old BSS shall include the GPRS Suspend information field in the 
Old BSS to New BSS IE in the HANDOVER REQUIRED message. 

The old BSS may recommend to the new BSS to allow pre-emption or not allow pre-emption by sending the "prec" bit. 
The new BSS may take this information into account when performing the Handover resource allocation procedure. 

The old BSS may inform the new BSS of radio information pertaining to the target cell in the "Target cell radio 
information" field element. The old BSS shall only send the "Target cell radio information" field element when it sends a 
single cell in the "Cell Identifier List (preferred)". This field element may be used by the new BSS (e.g. for radio channel 
selection). 

NOTE; It is not recommended that this information element is included if more than one cell is sent in the "Cell 
Identifier List (preferred)". 

The old BSS may inform the new BSS of the presently configured channel in the Current Channel Type 1 information 
element and in the Current Channel type 2 Field Element. The information contained may be used by the new BSS (e.g. 
when building the radio interface HANDOVER COMMAND message). Where discrepancies occur between the Current 
Channel Type 1 and the Current Channel Type 2 then the information in the Current Channel Type 2 shall take precedence 
if understood by the new BSS. 

The HANDOVER REQUIRED message shall be updated and repeated by the BSS with a periodicity of T7 until: 

- A HANDOVER COMMAND message is received from the MSC, or; 

- A RESET message is received, or; 



ETSI 



GSM 08.08 version 6.2.0 Release 1 997 24 TS 1 00 590 V6.2.0 (1 998-1 1 ) 

- The reason for the original HANDOVER REQUIRED message disappears e.g. the MS transmission improves, 
or; 

- All communication is lost with the MS as defined in GSM 04.08, and the transaction is abandoned, or; 

- The transaction ends, e.g., call clearing. 

3.1 .5.2 Handover Resource allocation 

This procedure has been defined to allow the MSC to request resources fi^om a BSS in a manner similar to that used for 
the assignment case. However it does not result in the transmission of any messages over the radio interface, only in the 
reservation of the resource(s) identified at the BSS, which awaits access of a MS on the reserved channel(s). These 
reserved resources are then indicated back to the MSC. 

In order to support this procedure the MSC sets up a BSSAP SCCP connection to the BSS. This connection is then used to 
support all BSSAP messages related to the dedicated resource(s). 

3.1 .5.2.1 Operation of tfie procedure 

The correct operation of the handover resource allocation procedure is as follows: 

The MSC sends a HANDOVER REQUEST message to the new BSS (note) from which it requires radio resources. This 
message contains details of the resource(s) required. If the MSC allocates the A interface circuits, and if the requested 
resource(s) is/are for speech or data the message also indicates the terrestrial resource that shall be used between the 
MSC and the BSS. The MSC should only ever ask for resources from the BSS that it knows are not totally incompatible 
with the nominated circuit. The type of channel(s) required can be different from the type of channel(s) in use, e.g. in the 
case of directed retry. The description of the resource(s) can either be a complete specification, or give the BSS some 
freedom in the selection (for instance channel rate selection, speech version selection etc.). The message may also specify 
the channel(s) in use, and, in case current channel mode is speech, the speech version used. 

On receipt of this message the new BSS shall choose suitable idle radio resources and, if the BSS allocates the A 
interface circuits and if needed, a terrestrial resource. 

The management of priority levels - relating to the Information Element "Priority" within the HANDOVER REQUEST 
message - is implementation dependent, under operator control. 

If queuing is managed, new requests which cannot be served immediately are put in the queuing file according to the 
indicated priority levels. 

(Refer to subclause 3.1.17 for Queuing Procedure) 

As a further operator option, the pre-emption indicators may (alone or along with the priority levels) be used to manage 
the pre-emption process, which may lead to the forced release or forced handover of lower priority connections. 

However, the pre-emption indicators (refer to subclause 3.2.2. 18), if given in the HANDOVER REQUEST, shall be 
treated on a per connection basis as follows: 

the last received "Pre-emption Vulnerability" indicator and priority levels shall prevail. 

if the "Pre-emption Capability" bit is set to 1 , then this allocation request can trigger the running of the pre-emption 
procedure. 

if the "Pre-emption Recommendation" bit indicates that pre-emption is recommended by the old BSS, then the new 
BSS may obey the recommendation and act appropriately based on "Pre-emption Capability Indication" bit. 

if the "Pre-emption Recommendation" bit indicates that pre-emption is not recommended by the old BSS, then the 
new BSS may obey this recommendation and ignore the "Pre-emption Capability" bit if it is set to 1. 

if the "Pre-emption Recommendation" bit is not present then the pre-emption procedure can be run. 

if the "Pre-emption Capability" bit is set to 0, then this allocation request cannot trigger the pre-emption procedure. 
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if the "Pre-emption Vulnerability" bit is set to 1, then this connection is vulnerable and shall be included in the pre- 
emption process or procedure and as such may be subject to forced release or forced handover. 

if the "Pre-emption Vulnerability" bit is set to 0, then this connection is not vulnerable to pre-emption and shall not 
be included in the pre-emption process and as such may not be subject to forced release or forced handover. 

if no Priority Information Element has been received, both "Pre-emption Capability" and "Pre-emption 
Vulnerability" bits shall be regarded as set to 0. 

If a radio resource is available then this will be reflected back to the MSC in a HANDOVER REQUEST 
ACKNOWLEDGE message. If the MSC gave the BSS some freedom in resource type selection, the choices made by the 
BSS are indicated in the HANDOVER REQUEST ACKNOWLEDGE message. If the BSS allocates the A interface 
circuits and such a circuit is needed, the circuit allocated by the BSS is indicated in the HANDOVER ACKNOWLEDGE 
message. The HANDOVER REQUEST ACKNOWLEDGE message sent by the new BSS shall contain the radio interface 
message HANDOVER COMMAND within its "Layer 3 Information" Information Element. This "Layer 3 Information" 
(which is in fact the RR-Layer 3 HANDOVER COMMAND) is transferred by the controlling MSC to the old BSS using 
the BSSMAP message HANDOVER COMMAND also within the Information Element "Layer 3 Information" of that 
BSSMAP message. The old BSS then sends to the MS over the radio interface the RR-Layer 3 HANDOVER COMMAND 
message. Information about the appropriate new channels and a handover reference number chosen by the new BSS are 
contained in the HANDOVER COMMAND. Knowledge of the channel in use at the old BSS allows the new BSS to 
minimize the size of the HANDOVER COMMAND message (i.e. to decide whether the mode of the first channel IE need 
not be included in the HANDOVER COMMAND). 

NOTE: The new BSS and the old BSS may be the same. 

When several circuit pools are present on the BSS MSC interface, and a circuit has been allocated by the HANDOVER 
REQUEST message, the "circuit pool" information field shall be included in the HANDOVER REQUEST 
ACKNOWLEDGE. The "circuit pool" field will indicate to the MSC the circuit pool of the CIC given in the 
HANDOVER REQUEST message. 

The sending of the HANDOVER REQUEST ACKNOWLEDGE by the new BSS to the MSC ends the Handover Resource 
Allocation procedure. The Handover Execution procedure can now proceed and this is given in subclause 3.1.5.3. 

The new BSS shall then take all necessary action to allow the MS to access the radio resource(s) that the new BSS has 
chosen, this is detailed in the GSM 05 series of Technical Specifications. If the radio resource(s) is a traffic channel or a 
group of traffic channels, then the new BSS shall at this point switch it through to the terrestrial resource indicated in the 
HANDOVER REQUEST message, and the necessary transcoding/rate adaption/encryption equipment enabled as detailed 
in GSM 04.08. 

The optimum procedure for switching through to the target cell at the MSC is not defined in these Technical 
Specifications. 

3.1 .5.2.2 Handover Resource Allocation Failure 

The following failure conditions of this procedure may occur: 

The BSS may not be able to use the terrestrial resource that the MSC has indicated in which case a HANDOVER 
FAILURE message will be returned with the Cause value set to: "requested terrestrial resource unavailable". 

The BSS may not be able to support the requested ciphering algorithm and in this case a HANDOVER FAILURE message 
shall be returned to the MSC with the Cause value "Ciphering algorithm not supported". 

If the requested channel type or resource (e.g. channel rate, speech version, etc.) indicated in the HANDOVER REQUEST 
message is not available in the BSS, then a HANDOVER FAILURE message shall be returned to the MSC. The 
appropriate failure cause will be included in the message (Cause value: "requested transcoding/rate adaptation 
unavailable" or "requested speech version unavailable"). 

The generation of the HANDOVER FAILURE message terminates the procedure and allows all references in the new 
BSS to be released. 

If, on reception of the HANDOVER REQUEST by the BSS, the circuit pool implied by the CIC information element is 
incompatible with the channel type indicated (that is, the pool does not support any of the radio resources indicated by the 
channel type) a HANDOVER FAILURE shall be returned to the MSC with the failure cause set to "circuit pool 
mismatch". 
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If, on reception of the HANDOVER REQUEST by the BSS, the circuit pool impHed by the CIC is compatible with the 
channel type indicated (that is, the pool supports at least one of the radio resource types indicated by the channel type), but 
the BSS still wishes to change the circuit pool, it sends a HANDOVER FAILURE with the cause "switch circuit pool" 
and the "circuit pool list" information element. 

The "circuit pool" information element, when present in the HANDOVER FAILURE, indicates to the MSC which circuit 
pool the CIC indicated in the HANDOVER REQUEST belongs to. This can be used by the MSC to correct its tables 
(CIC/circuit pool). The "circuit pool list" information element, when present in the HANDOVER FAILURE, is used when 
the BSS wishes to indicate to the MSC its preferred circuit pools. The circuit pools in the "circuit pool list" information 
element shall be given in order of preference. In the case of a HANDOVER FAILURE with the cause "circuit pool 
mismatch", the MSC may decide to block the circuit and to send an O & M notification. 

Other possible cause values which may be returned with the HANDOVER FAILURE message are: "equipment failure", 
"no radio resource available", "O&M intervention". 

The MSC may not be able to use the terrestrial resource that the BSS has indicated. In this case, the procedure is 
nevertheless considered terminated successfully, and it is up to the MSC to correct the situation, e.g., by a circuit re- 
selection procedure. 

Further actions in the MSC concerning handover depend upon the handover algorithm which is operator dependent. If an 
unrecognised Handover Failure cause value is received, the Class of the cause value should be used to determine the 
MSC's action. 

3.1 .5.2.3 Abnormal conditions 

If after receipt of a HANDOVER REQUEST message, the new BSS receives another HANDOVER REQUEST message 
on the same SCCP connection, then the later message will be discarded. 

If the BSS receives a HANDOVER REQUEST allocating a terrestrial circuit which the BSS has marked as blocked by a 
previous blocking procedure, then a HANDOVER FAILURE shall be returned to the MSC with the Cause set to 
"requested terrestrial resource unavailable". A single global BLOCK message (not repeated and not guarded by timer Tl) 
shall be sent for that concerned terrestrial circuit. 

If the BSS receives a HANDOVER REQUEST message indicating a target cell which is not controlled by the BSS, then a 
HANDOVER FAILURE message shall be returned to the MSC with the cause set to "invalid cell". 

3.1.5.3 Handover execution 

Handover execution in the context of the BSS/MSC interface is the process whereby an MSC instructs an MS to tune to a 
new dedicated radio resource or to a group of radio resources, which may be on a different cell. 

3.1 .5.3.1 Operation of the procedure 

The correct operation of the procedure is as follows: 

The BSSMAP HANDOVER COMMAND message is generated by the MSC and transmitted over the BSSAP connection 
to the old BSS which is currently supporting the concerned MS. At the old BSS timer T8 is started on the receipt of the 
BSSMAP HANDOVER COMMAND message. A radio interface HANDOVER COMMAND message is then sent by the 
old BSS, to the concerned MS. The message contains a handover reference number, previously allocated by the new BSS. 

The BSSMAP HANDOVER COMMAND message generated by the MSC may optionally contain a Cell Identifier IE 
which indicates to the old BSS the target cell identity to which the handover is to be performed. In case of failure, this 
information allows the old BSS to know on which cell the handover failed. 

When the MS accesses the radio resource(s) of the new BSS with a HANDOVER ACCESS burst which contains the 
received handover reference number then: 

The new BSS checks the handover reference number to ensure that it is the same as expected, and hence that there 
is a high probability that the correct MS has been captured (if the handover reference is not as expected then the 
new BSS shall wait for an access by the correct MS); 

If the handover reference number is as expected, the new BSS shall send a HANDOVER DETECT message to the 
MSC; 
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When the MS is successfally in communication with the network, i.e. the RR message HANDOVER COMPLETE 
has been received from the MS, then the new BSS will immediately send a BSSMAP message HANDOVER 
COMPLETE to the MSC and terminate the procedure. 

In the case where the new BSS hands the MS to a Group call channel, the BSS shall send a CLEAR REQUEST with cause 
"Joined group call channel" directly after having sent the HANDOVER COMPLETE message. 

In the case of point to point calls the MSC shall terminate the procedure with the old BSS by sending a CLEAR 
COMMAND with cause "Handover successful". 

In the case of a handover from a Group call channel the MSC shall terminate the procedure by sending a HANDOVER 
SUCCEEDED message. 

The old dedicated radio resource(s) and connected terrestrial resource shall remain assigned until either the MSC 
instructs the old BSS to release the resource(s) by a CLEAR COMMAND or a reset occurs. 

After the completion of the handover procedure, until the connection is released or the MSC performs an assignment, any 
dedicated resource assigned to the mobile station, e.g. at internal handover, must be in accordance with the description in 
the HANDOVER REQUEST message. 

If either: 

a CLEAR COMMAND is received from the MSC; 

or 

a reset is received from the MSC, 

before a MS with the correct handover reference accesses the new BSS then the radio resources shall be released and the 
terrestrial resources marked as idle 

The relevant radio interface layer 3 procedures are described in GSM 04.08. 

The MSC always terminates this procedure by use of a clear sequence as follows; 

The MSC sends a CLEAR COMMAND to the old BSS. On receipt of a CLEAR COMMAND from the MSC the 
old BSS shall stop timer T8 and release all involved resources that were allocated to the MS that had been handed 
over and returns a CLEAR COMPLETE message to the MSC. 

On receipt of the CLEAR COMPLETE, the MSC shall initiate the release of the SCCP connection to the old BSS 
and thereby terminate association with the old BSS for this process. 

3.1.5.3.2 Handover Failure 

If a HANDOVER FAILURE radio interface message is received from the MS on the old (main) channel by the old BSS, 
the old BSS shall then send to the MSC the BSSMAP message HANDOVER FAILURE. If the radio interface 
HANDOVER FAILURE message is the result of the MS returning to the old BSS after failing to establish on the new BSS, 
then the cause value "radio interface failure, reversion to old channel" shall be included in the BSSMAP message 
HANDOVER FAILURE. Furthermore, it is recommended that the air interface RR cause be included as well in this 
message. 

If the MSC receives the BSSMAP HANDOVER FAILURE message from the old BSS (with any cause value), the 
handover procedure at the target new BSS is then terminated by the MSC using a clear sequence as follows: 

The MSC sends a CLEAR COMMAND cause "Radio interface failure, reversion to old channel" to the new BSS. 
On receipt of a CLEAR COMMAND from the MSC the new BSS shall release all involved resources that were 
allocated during the handover resource allocation procedure and returns a CLEAR COMPLETE message to the 
MSC. 

On receipt of the CLEAR COMPLETE, the MSC shall initiate the release of the SCCP connection to the new BSS 
and thereby terminate association with the new BSS for this process. 

The call between the MS and the old BSS and between the old BSS and the MSC shall continue as if there had been no 
handover attempt. 

Further actions in the MSC concerning handover depends on the handover algorithm which is operator dependent. 
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In the case of a talker on a group call channel the MS may release the uplink whilst the handover is being 
performed, in this case the old BSS shall cancel the handover internally, the MSC should cancel the handover and 
initiate the release of the A interface resources allocated in the new BSS. 

3.1.5.3.3 Abnormal Conditions 

Whilst the handover execution procedure is in operation, any other messages received at the old BSS relating to this 
connection and concerning assignment, handover, or cipher mode control should be discarded. 

Whilst the handover execution procedure is in operation the old BSS should not attempt to invoke any other procedure 
related to this call e.g. handover required indication. 

If at the old BSS a CLEAR COMMAND message from the MSC or a HANDOVER FAILURE message from the MS is not 
received before the expiry of timer T8 then the old BSS shall release the dedicated radio resources. A BSSMAP message 
CLEAR REQUEST is also sent to the MSC with a cause "Radio Interface Message Failure". The terrestrial resource in 
the old BSS shall remain assigned until a CLEAR COMMAND is received from the MSC, at which point the old BSS 
shall mark the terrestrial resources as IDLE and return a CLEAR COMPLETE message to the MSC. The MSC shall 
subsequently release the SCCP connection to the old BSS and thereby terminate association with the old BSS for this 
process. 

The MSC shall also initiate release of the resources allocated by the new BSS during the handover resource allocation 
procedure by sending a CLEAR COMMAND to the new BSS. The new BSS shall release all the resources that were 
assigned for that aborted handover and return a CLEAR COMPLETE to the MSC. The MSC shall subsequently release the 
SCCP connection to the new BSS and thereby terminate association with the new BSS for this process. 

3.1 .6 Internal Intra-Cell Handover Procedure 

The definition of internal intra cell handover is given in clause 5. 

It is optional that a BSS support internal intra-cell handover. However if it is supported, it should be as follows: 

It should be possible to inhibit internal intra-cell handover at an BSS that supports it by operation and maintenance 
command. 

Internal intra-cell handover occurs between channels on the same cell. It is decided and executed autonomously by the 
BSS, so that no message is generated at the BSS-MSC interface, until the completion of the handover execution, when the 
BSS sends a HANDOVER PERFORMED message over the SCCP and terrestrial resources that are presently assigned to 
that call. Changes in type of resources (for instance channel rate change, speech version change, ciphering algorithm 
change) are indicated in the HANDOVER PERFORMED message. 

The decision process in the BSS is based on the internally available radio and resource parameters taking into account the 
previously received information from the MSC in the ASSIGNMENT REQUEST or HANDOVER REQUEST. 

The relevant radio interface layer 3 procedures (dedicated channel assignment) are described in GSM 04.08. 

In the case of group calls the BSS may perform an intra-cell handover for a talker from a dedicated channel to a 
group call channel, in this case the HANDOVER PERFORMED message is sent by the BSS over the SCCP 
connection that was previously assigned to the talker, followed by a CLEAR REQUEST with the cause "Joined 
group call channel", the MSC shall release the dedicated A interface resources. 

In the case of group calls the BSS may perform an Intra-cell handover for a talker from a Group call charmel to a 
dedicated channel, in this case the BSS performs external handover. 

3.1 .7 Internal Inter-Cell Handover Procedure 

The definition of internal inter-cell handover is given in clause 5. 

It should be possible to inhibit internal inter-cell handover at a BSS that supports it by operation and maintenance 
command. 

Multi cell BSSs would normally be expected to support internal inter-cell handover, however it is optional that they do 
so. However if it is supported, it should be as follows: 
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Internal inter-cell handover occurs between channels pertaining to different cells of the same BSS. It is decided and 
executed autonomously by the BSS, so that no message is generated at the BSS-MSC interface, until the completion of the 
handover execution, when the BSS sends a HANDOVER PERFORMED message over the SCCP and terrestrial resources 
that are presently assigned to that call. Changes in type of resources (for instance channel rate change, speech version 
change, ciphering algorithm change) are indicated in the HANDOVER PERFORMED message. 

A special case of internal handover occurs when the handover is triggered by the assignment procedure, e.g. directed 
retry. In this case the HANDOVER PERFORMED message need not be sent as the equivalent response is provided by the 
ASSIGNMENT COMPLETE message. 

The decision process in the BSS is based on the internally available radio and resource parameters taking into account the 
previously received information from the MSC in the ASSIGNMENT REQUEST or HANDOVER REQUEST. 

The relevant radio interface layer 3 procedures (for handover) are described in GSM 04.08. 

Internal inter-cell handover for group calls may be performed from either dedicated to dedicated channels, or dedicated to 
group call channels, or group call to group call channels. 

In the case of group calls, the BSS may perform an internal inter-cell handover for a talker from a dedicated channel to a 
Group call channel, in this case the HANDOVER PERFORMED message is sent by the BSS over the SCCP connection 
that was previously assigned to the talker. The BSS will send a CLEAR REQUEST with the cause "Joined group call 
channel". 

3.1 .8 Handover Candidate Enquiry 

The purpose of this procedure is to allow the MSC to ascertain if it is possible to handover any MSs that are currently 
being served by a particular cell to another nominated cell. The procedure uses both global and dedicated resource 
messages, and is relevant to an individual cell. 

The algorithm in which a MSC decides on starting a handover enquiry procedure is operator dependent. 

3.1.8.1 Successful Operation 

The procedure operates as follows: 

The MSC sends a HANDOVER CANDIDATE ENQUIRE message to a BSS. The message indicates that the MSC wishes 
the BSS to identify handover candidates in a particular cell, that can be handed over to other nominated cells. The 
maximum number of candidates is also indicated to the BSS. 

For each selected MS candidate the BSS will send to MSC a single, once only, HANDOVER REQUIRED message (not 
guarded by timer T7), over each of the appropriate SCCP connections. If the BSS was already generating HANDOVER 
REQUIRED messages for a selected MS then the BSS will continue to do so. However the Cause IE of the next 
HANDOVER REQUIRED message (at the expiry of timer T7) will be set to "Response to MSC invocation" to indicate 
that the message is generated in response to a HANDOVER CANDIDATE ENQUIRE message. But as this HANDOVER 
REQUIRED was already being generated before the handover enquiry procedure was started, that HANDOVER 
REQUIRED would be guarded by timer T7. So in the instance of next expiry of timer T7, the BSS shall continue sending 
HANDOVER REQUIRED message but the Cause IE value shall revert back to the original Cause IE value. 

When the last HANDOVER REQUIRED message has been sent for all the selected MS candidates, the BSS returns to the 
MSC a HANDOVER CANDIDATE RESPONSE message giving the number of candidates identified, and terminating the 
handover enquiry procedure. 

Only one handover enquiry procedure may be invoked on any given cell at any one time. 

3.1 .8.2 Abnormal conditions 

If at the BSS a HANDOVER CANDIDATE ENQUIRE message is received when a handover enquiry procedure has 
ab-eady been invoked then the new HANDOVER CANDIDATE ENQUIRE message shall be discarded. 
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3.1 .9 Release of Radio Resource And Terrestrial Resource 

3.1 .9.1 Release Due To Transaction Completion 

The release of assigned radio resources at the end of a transaction will take place as follows: 

Release negotiation will take place directly between the MS and MSC using transparent messages via the DTAP in the 
BSS (see GSM 04.08). The MSC will then send a BSSMAP CLEAR COMMAND, indicating that the radio resource(s) 
should be released. After the BSSMAP CLEAR COMMAND has been sent, the MSC shall not send further BSSAP 
connection oriented messages on this particular connection, except CLEAR COMMAND. 

If the BSS allocates the A interface circuits, the MSC shall release the circuit allocated to the connection, if any, before 
sending the CLEAR COMMAND. 

When the BSS receives the CLEAR COMMAND: 

the guard timer defined in GSM 04.08 is started and clearing on the radio interface initiated. 

the BSS marks any assigned terrestrial resources as idle and returns a CLEAR COMPLETE message to the 
MSC. (The BSS need not wait for the radio channel release to be completed or for the guard timer to expire 
before returning the CLEAR COMPLETE message.) 

If the MSC allocates A interface circuits, on receipt of CLEAR COMPLETE, the MSC releases any assigned terrestrial 
resources. 

3.1 .9.2 Release due to BSS generated reason 

If a radio channel release is required because of a BSS generated reason (e.g. "O and M intervention", "equipment 
failure") then, the BSS shall generate a CLEAR REQUEST message towards the MSC. This message shall include a 
Cause Information Element, indicating the reason for the failure. 

If transmission from the MS is lost then a CLEAR REQUEST message shall be sent to the MSC. 

On receipt of a CLEAR REQUEST the MSC shall initiate the release, as defined above, by sending a CLEAR 
COMMAND message. On receipt of this message the BSS shall, if the resources are not already internally released, 
release the resources in the normal way. The procedure is always terminated with a CLEAR COMPLETE to the MSC. 

In the case of a group call talker the BSS may handover the mobile on to a group call channel, in this case the BSS shall 
initiate a release of A interface resources by sending a CLEAR REQUEST with the cause "Joined group call channel". 
The MSC in its turn shall release the dedicated resources associated with the talker. 

3.1 .9.3 Release due to successful handover 

If a radio channel release is required because of a handover being successfully completed on another BSS, then the 
resources at the old BSS are released by the MSC using the clearing sequence with a Cause value; "handover successful". 

In the case of handover of a group call talker from a group call channel the MSC shall send a HANDOVER SUCCEEDED 
message to the old BSS. 

3.1.10 Paging 

PAGING messages for all MSs shall be sent via the BSSMAP as a connectionless message. These will include the IMSI 
of the MS to allow derivation of the paging population number; they may also include an indication of which combination 
of channels will be needed for the subsequent transaction related to the paging. This type of PAGING message will then 
be stored and a corresponding radio interface paging message transmitted over the radio interface at the appropriate time. 

It should be noted that each PAGING message on the MSC-BSS interface relates to only one MS and therefore the BSS 
has to pack the pages into the relevant GSM 04.08 radio interface paging message. 

If a radio interface PAGING RESPONSE message is received then the relevant connection is set up towards the MSC as 
described in GSM 08.06 and the radio interface PAGING RESPONSE message is passed to the MSC in a COMPLETE 
LAYER 3 INFORMATION message. 
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A single PAGING message across the MSC to BSS interface contains information on the cells in which the page shall be 
broadcast. 

3.1.11 Trace Invocation 

The purpose of the trace invocation procedure is to inform the receiving entity that it should begin producing a trace 
record on this particular transaction. 

The trace is invoked either by the MSC sending a MSC INVOKE TRACE message to the BSS or by the BSS sending a 
BSS INVOKE TRACE message. 

The events and parameters to be recorded are indicated in the "Trace type" information element. 

A "Forwarding indicator" element may be used in the BSS INVOKE TRACE to indicate if the trace is to be continued 
after handover to another BSS. If thus indicated, The MSC should forward the BSS INVOKE TRACE to the BSS-B and 
also store it to send to any subsequent BSS during the lifetime of the call. 

The remaining elements, when received, are to be passed transparently to the OMC receiving the trace record. 

The element "OMCId", if present, indicates the OMC to which the record is destined. 

In sending the BSS INVOKE TRACE message, the BSS may allocate and include a "BSS transaction reference". Similarly 
in the MSC INVOKE TRACE message, the MSC may allocate and include an "MSC transaction reference" (typically a 
call reference). The transaction reference is contained in the information element "Transactionid". 

The message includes a trace reference which is allocated by the entity which triggered the trace. 

The element "Triggerld", if present, indicates the entity which triggered the trace. 

The trace reference, triggerld and transactionid Information Elements are used to tag the trace record to allow simpler 
construction of the total record by the entity which combines trace records. 

The messages are not acknowledged and are sent as a connection oriented message on the connection on which a trace is 
required. 

3.1.12 Flow Control 

These procedures are defined to give some degree of flow control. At the BSS processor overload and CCCH scheduler 
overload are catered for, and at the MSC processor overload is catered for. 

3.1.12.1 Philosophy 

The philosophy used is to stem the traffic at source with known effect on the service. The algorithm used is: 

On receipt of the first OVERLOAD message or signalling point congested information, the traffic is reduced by 
one step. At the same time, timers T5(T17) and T6(T18) are started. During T5(T17) all received overload 
messages or signalling point congested information are ignored in order not to reduce the traffic too rapidly. 
Reception of an OVERLOAD message or signalling point congested information after expiry of T5(T17) but still 
during T6(T18) , will decrease the traffic load by one more step, and restart T5(T17) and T6(T18). 

This step by step reduction of traffic is continued until maximum reduction is obtained by arriving at the last step. 
If T6(T18) expires (i.e. no OVERLOAD message or signalling point congested information is received during 
T6(T18)) the traffic will be increased by one step and T6(T18) will be started, unless full load has been resumed. 

NOTE: Timers T5 and T6 are running in the MSC whilst Timers T17 and T18 are running in the BSS. 

The number of steps and the method of reducing the load is considered to be an implementation specific function. 

There may be other traffic control mechanisms from O and M activities occurring simultaneously. 
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3.1 .1 2.2 Processor Overload at the MSC 

The MSC can indicate to the BSS that it is in a congested state by sending an OVERLOAD message. This is sent as a 
connectionless global message. 

At the BSS receipt of this message causes the reduction of random access traffic using the method described in subclause 
3.1.12.1. 

For example, the amount of random access traffic could be reduced by using the access control class in the system 
information message of GSM 04.08. 

3.1 .1 2.3 Processor/CCCH overload at the BSS 

If the CCCH scheduler at the BSS is overloaded (queue passed a predefined threshold) then the BSS sends an 
OVERLOAD message to the MSC with the appropriate cause (Cause value: "CCCH overload") and indicating the cell in 
question. 

If the BSS processing is overloaded then the BSS sends an OVERLOAD message with the Cause value: "processor 
overload". 

The MSC originated traffic is reduced in accordance with the method described in subclause 3.1.12.1. 

3.1 .1 2.4 Message throughput congestion 

If the lower layers of the protocol become congested then it is assumed that the MTP congestion indication will take place 
(see GSM 08.06) and the source of the traffic will receive primitives from the transport protocols resulting in it reducing 
the generated load. 

A suitable method to achieve this reduction could be based on that given in subclause 3.1.12.1. 

3.1.13 Classmark Handling Procedures 

3.1 .1 3.1 Classmark request procedure 

The purpose of this procedure is to allow the MSC to trigger a classmark updating procedure. This is done by sending a 
CLASSMARK REQUEST message to the BSS on the appropriate SCCP connection. When receiving this message the 
BSS shall initiate the appropriate actions on the radio path. 

3.1 .1 3.2 Classmark updating procedure 

The purpose of the classmark updating procedure is to inform the receiving entity about classmark information received 
from the MS. 

At any point when an SCCP connection has been established for BSSAP messages, the BSS must be able to send to the 
MSC a CLASSMARK UPDATE message if a classmark update is received from the MS. This message contains 
information on several transmission parameters relevant to the MS in communication with the network. 

If the MSC has already initiated a handover for the concerned MS by sending a HANDOVER REQUEST message when 
the CLASSMARK UPDATE message is received, the MSC shall send a CLASSMARK UPDATE message to the target 
BSS when the MS is successfully in communication with the network on the new (main) channel. If this CLASSMARK 
UPDATE message is received in the target BSS after a new classmark has been received from the Mobile Station the 
CLASSMARK UPDATE message from the MSC shall be ignored. 

This message is sent as a BSSAP message over the appropriate SCCP connection 

This procedure will be used where the power class of the MS changes or if the network requests the MS to send the 
classmark information whilst the MS has one or more dedicated resources. 

The procedure will also be used to send classmark information to the MSC if the MS immediately after initial L3 message 
sends additional classmark information. In this case the BSS may as an option suppress or delay the sending of the 
CLASSMARK UPDATE message to the MSC. 
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3.1.14 Cipher Mode Control 

3.1.14.1 Successful Operation 

The cipher mode control procedure allows the MSC to pass cipher mode information to the BSS to select and load the 
user data and signalling encryption device with the appropriate key. 

This is achieved by sending the BSS a CIPHER MODE COMMAND message. Receipt of the message at the BSS will 
cause the generation of a radio interface CIPHERING MODE COMMAND message and, if applicable, invoke the 
encryption device and start stream ciphering as described in GSM 04.08 and GSM 03.20. 

If within the CIPHER MODE COMMAND, the signalling element "Cipher response mode" is present and indicates "IMEI 
must be included by the Mobile Station", then the BSS shall request in the radio interface message CIPHERING MODE 
COMMAND the Mobile Station to include its IMEI in the radio interface CIPHERING MODE COMPLETE message (see 
GSM 04.08, subclause 'Ciphering mode setting initiation' ). 

In the CIPHER MODE COMMAND the MSC specifies which of the ciphering algorithms may be used by the BSS. The 
BSS then selects an appropriate algorithm, taking into account the MS ciphering capabilities. The CIPHER MODE 
COMPLETE message returned to the MSC indicates the chosen ciphering algorithm. The set of permitted ciphering 
algorithms specified in the CIPHER MODE COMMAND shall remain applicable for subsequent Assignments and Intra- 
BSS Handovers. 

The CIPHER MODE COMMAND and CIPHER MODE COMPLETE messages are sent as connection oriented messages 
via the appropriate SCCP connection. 

Receipt of the radio interface CIPHERING MODE COMPLETE message (or other correctly deciphered layer 2 frame) 
from the radio interface is used internally within the BSS to achieve radio interface ciphering synchronisation (see GSM 
04.08). When the BSS receives the radio interface CIPHERING MODE COMPLETE from the MS a CIPHER MODE 
COMPLETE message is returned to the MSC. If the CIPHERING MODE COMPLETE message received on the radio 
interface contained more than two octets, then the BSS shall include in the BSSMAP CIPHER MODE COMPLETE 
message a "Layer 3 message contents" signalling element containing octets 3 up to n (where n is the length of that 
CIPHERING MODE COMPLETE radio interface message) of that radio interface CIPHERING MODE COMPLETE 
message. 

3.1.14.2 Abnormal Conditions 

If the BSS is unable to support the ciphering algorithm specified in the CIPHER MODE COMMAND message then it shall 
return a CIPHER MODE REJECT message with Cause value "Ciphering algorithm not supported". A CIPHER MODE 
REJECT message shall also be returned if the MSC requests a change of ciphering algorithm when ciphering is already 
active. 

3.1.15 General SCCP Abnormal Conditions 

If a user-out-of-service information or signalling-point-inaccessible information is received by the BSSAP or BSSOMAP 
no new attempt to establish SCCP connections towards the affected point code will be started until the corresponding 
user-in-service information or signalling-point-accessible information is received. 

When a user-out-of-service information or signalling-point-inaccessible is received by the BSS an optional timer may be 
started. When the timer expires all the SCCP connections towards the affected point code will be released. When the 
user-in-service or signalling-point-accessible is received, the timer is stopped. 

If for any reason an SCCP connection is released, the optional timer expires or a connection refusal is received while any 
of the BSSAP procedures are being performed or while a dedicated resource is still allocated the following actions are 
taken: 

At BSS: 

The radio resources associated with the SCCP connection are cleared by an appropriate radio procedure. 

Any BSS procedure relating to that connection is abandoned. 

The resources allocated to the call associated to the connection are released. 



ETSI 



GSM 08.08 version 6.2.0 Release 1 997 34 TS 1 00 590 V6.2.0 (1 998-1 1 ) 

At MSC: 

The call associated with the SCCP connection is cleared as soon as possible. 

At the BSS, communication over assigned radio channels shall be assumed to be continuing until either the SCCP 
connection is lost, a clearing sequence is received, or no signal is received from an MS for longer than the guard time 
defined in GSM 04.08. If the BSS recognises that a call has terminated then a CLEAR REQUEST message should be 
generated. 

If a 2Mbit/s system fails and one of the standard alarms is received, no action is taken at the BSS on the calls associated 
with the traffic channels involved. 

At the MSC, calls should be cleared if either subscriber clears, or if the BSS sends a CLEAR REQUEST message. 
Clearing of affected calls by the MSC may take place after loss of the traffic channels for a period defined by the 
operator. 

For the procedures controlled by the MSC, and in particular procedures where the MSC sends a request for resources at 
the BSS and waits for an acknowledge, the implementation in the MSC must provide means for avoiding deadlock 
situations at the BSS as e.g. hanging resources. 

3.1.16 Initial MS message 

When the SCCP connection establishment is performed by the BSS, the radio interface initial L3 message received from 
the MS (piggybacked on the SABM frame) is processed as follows: 

The BSS shall analyse the protocol discriminator of the message. 

If the BSS does not support the protocol, reactions of the BSS are specified in GSM 04.08. If the BSS supports the 
protocol, it shall, if the protocol is PDSS2, continue as specified in GSM 03.63; otherwise the BSS shall continue as 
follows: 

The BSS shall analyse the message to a level which allows the extraction by the BSS of the Classmark information. 
However, the entire radio interface initial L3 message (e.g. CM SERVICE REQUEST, PAGING RESPONSE, CM 
REESTABLISHMENT REQUEST, LOCATION UPDATING REQUEST, IMSI DETACH, NOTIFICATION 
RESPONSE, IMMEDIATE SETUP) is also passed to the MSC, using a COMPLETE LAYER 3 INFORMATION 
message. The BSS does not analyse the contents of the initial layer 3 message, other than the Classmark information. 

The BSS may also give the MSC a description of the channel on which the initial layer 3 message was received. 

3.1.17 Queuing Indication 

The purpose of the QUEUING INDICATION message is t inform the MSC about a delay in the allocation of the necessary 
dedicated radio resources. The procedure is only relevant if the system is using a queuing procedure for traffic channels in 
the BSS, (subclause 3.1.17.1) and/or for handover of traffic channels (subclause 3.1.17.2) 

3.1 .1 7.1 Operation of the procedure in case of assignment procedure 

After the ASSIGNMENT REQUEST message without having the necessary TCH available the ASSIGNMENT 
REQUEST message shall be put into a queue; the QUEUING INDICATION message shall be returned to the MSC and the 
timer Til shall be started. The timer value Til specifies the maximum queuing delay and is determined by the operator. 

The procedure shall be terminated with a successful or unsuccessful assignment of the required traffic channel(s) by 
sending an ASSIGNMENT COMPLETE or an ASSIGNMENT FAILURE message, respectively, to the MSC. 

If the timer Tl 1 expires the ASSIGNMENT REQUEST message shall be removed from the queue and a CLEAR 
REQUEST message shall be sent to the MSC, with the Cause "no radio resource available". 
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3.1 .1 7.2 Operation of the procedure in case of hand-over resource allocation 
procedure 

After the HANDOVER REQUEST message without having the necessary TCH available the HANDOVER REQUEST 
shall be put into a queue; the QUEUING INDICATION message shall be returned to the MSC and the timer Tqho shall be 
started. The timer value Tqho specifies the maximum queuing delay and is determined by the operator. 

The procedure shall be terminated with a successful or unsuccessful reservation of the required traffic channel(s) by 
sending a HANDOVER REQUEST ACKNOWLEDGE or a HANDOVER FAILURE message, respectively, to the MSC. 

If the timer Tqho expires the HANDOVER REQUEST shall be removed from the queue and a HANDOVER FAILURE 
message shall be sent to the MSC with the Cause value "no radio resource available". 

3.1.18 Data Link Control SAPI not Equal to "0" 

The radio interface can support data links with the SAPI not equal to "0". 

3.1 .1 8.1 Data link set up across the radio interface 

This subclause deals with the impact of data link establishment (SAPI not equal to "0") on the MSC to BSS interface. 

3.1.18.1.1 MS to MSC direction 

In the MS to MSC direction the receipt of a layer 3 message via a data link where SAPI does not equal "0" at the BSS 
will be transferred to the MSC as a DTAP message with the DLCI (Data Link Connection Identification) octet set 
appropriately. 

3.1.18.1.2 MSC to MS Direction 

Receipt of a layer 3 (DTAP) message from the MSC with the SAPI (indicated in the DLCI) not equal to "0" will cause 
one of the following actions: 

the triggering of a data link set up to support the message transfer across the radio interface if no suitable link 
exists; 

the transmission of the message to the MS if a suitable link has already been established; 

- the sending of a BSSMAP SAPI "N" REJECT message to the MSC if for any reason the data link cannot be 
established, A Cause Information Element is included; typical Cause values are: "O&M intervention", "processor 
overload", "BSS not equipped", "MS not equipped". 

3.1 .18.2 Choice of the signalling link 

When the BSS relays a message of the PDSS 1 protocol received on the air interface to the MSC, it shall indicate in the 
DLCI (see GSM 08.06) on which control channel and SAPI the message was received. 

When the MSC sends a DTAP message to the BSS, it shall, 

- if the protocol of the corresponding air interface layer 3 message is PDSS 1 , specify on which control channel and 
SAPI of the air interface the L3 message shall be sent 

- otherwise not further specify the control channel on the air interface. 

When the BSS relays an air interface L3 message received in a DTAP message on the A interface to the MS, it shall 

- if the DLCI does not further specify the signalling channel of the air interface, send it on the appropriate signalling 
Hnk 

- if the BSS supports PDSS 1 and the DLCI specifies which control channel is to be used for transmission on the air 
interface, the BSS shall transfer the air interface L3 message on the specified control channel. 
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NOTE: If the BSS does not support PDSSl, it considers the part of the DLCI possibly indicating the control channel 
to be used on the air interface as spare bits, see GSM 08.06. 

3.1.19 BSSMAP Error Handling 

To allow for the introduction of new functions the following rules shall be used to determine the actions of a receiving 
entity when it receives a message, part or all of which it is unable to understand. As the recipient is unable to tell the 
difference between a new, previously unspecified coding and an erroneous coding, the recipient also uses the same rules 
for error handling. 

The robustness of a recipient in handling erroneous messages does not relax the requirement that the transmitter shall obey 
this Technical Specification. However, it is intended that functionality can be gradually added to an entity, and no 
obstacle to intermediate phase equipment is intended. 

With the exception of subclause 3.1.19.6, the specific 'abnormal case' handling in other subclauses of 08.08 take 
precedence over this subclause. 

3.1.19.1 Definitions of Types of Information Elements 

The following definitions shall be used in subclause 3.1.19 and only in this subclause. 

Essential Elements 

These are the conditional elements when the condition for their reception is fulfilled, plus the Mandatory elements 
excluding the Cause value information element (3.2.2.5). 

Mandatory Elements 

These are the Information Elements marked as 'M' in subclause 3.2.1. 
Non-Essential Elements 

Non-essential elements are all the information elements that are not defined as essential. 
Conditional Elements 

In the indicated messages the following elements are conditional: 

Circuit identity code in 3.2.1.1 and 3.2.1.8. 

NOTE: A conditional IE is an IE whose presence or absence in a message can be determined by information 
contained in the rest of the message. 
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Transparent Elements 

The following elements are defined as transparent: 

fortheBSS: TMSI; 
RR cause; 

Layer 3 information in the BSSMAP HANDOVER COMMAND message; and 
Layer 3 message contents; and for the MSC: Resource situation. 

Layer 3 information in the BSSMAP HANDOVER REQUEST ACKNOWLEDGE message; and 
"Old BSS to new BSS information" in the BSSMAP HANDOVER REQUIRED message 

Non-Transparent Elements 

Non-transparent elements are all the information elements that are not defined as transparent. 

3.1.19.2 Erroneous Events 

The following events shall be regarded as errors by the recipient: 

1 a message whose type is non-existent, unrecognisable, not consistent with the recipient's state, or, that is sent in 
the wrong direction. This includes messages that should use the SCCP connectionless service but that are 
received on an SCCP connection, and vice versa; 

2 a missing essential information element; 

3 use of a reserved codepoint in an information element that is both essential and non-transparent; and 

4 an essential and non-transparent information element which is too short (the contents of any Length' octet shall 
be used to determine the boundary of the element). 

When a recipient detects one or more of these events it shall return the appropriate error message with a suitable Cause 
value and the message shall be discarded. 

3.1.19.3 Non-erroneous Events 

The following events shall not be regarded as errors by the recipient: 

1 spare bits with an unexpected value in any information element; 

2 the use of additional octets in any information element with a length octet; 

3 a missing non-essential information element; 

4 use of reserved codepoints in any non-essential information element or in any transparent information element; 
and 

5 a non-essential information element or a transparent information element whose length is too short. 

When the recipient detects one or more of these events the receiving entity shall ignore the information that it is unable to 
understand and treat the message on the basis of the information that remains. 

Additionally, 

all information in a message that is received after the start of an information element with an unrecognisable 
identifier shall be ignored. The message shall be accepted or rejected solely on the basis of the information 
received before the start of the unrecognisable element; 



and. 



when more information elements of a particular type are received than are expected, the last one(s) shall be 
ignored. 
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3.1.19.4 other Events 

The following events should be treated on a case by case basis and the outcome may depend upon the capabilities of the 
recipient. 

1 The recipient may accept messages that contain information elements that do not appear to be in the correct 
sequence. Elements that occur more than once in a message shall be assumed to have been transmitted in the 
correct order. Recipients that do not accept out of sequence information elements shall regard the message as 
containing unexpected and/or missing information elements and follow the procedures of subclauses 3.1.19.1 
and/or 3.1.19.2. 

2 Where a field in an information element contains a value, which the recipient knows to be incorrect, the 
recipient shall either reject the message or it shall ignore that field, and treat the information that remains in the 
message. 

(e.g. if the 'Number of MSs' in a Handover Candidate Response message is greater than the number of 
Handover Required messages received). 

3.1 .1 9.5 Appropriate Error Message and Cause Value 

The choice of error message depends upon the received message type: 

Received message type Error Message 

ASSIGNMENT REQUEST ASSIGNMENT FAILURE 

HANDOVER REQUEST HANDOVER FAILURE 

HANDOVER REQUIRED 

if "Response Request" i.e. is present HANDOVER REQUIRED REJECT 

if "Response Request" i.e. is not present CONFUSION 

CIPHER MODE COMMAND CIPHER MODE REJECT 

VGCSA'BS SETUP VGCSA^BS SETUP REFUSE 

VGCSA'BS ASSIGNMENT REQUEST VGCSA^BS ASSIGNMENT FAILURE 

CONFUSION an error message shall not be used 
all other message types CONFUSION 

When a problem is experienced with a message sent over an SCCP connection, the error message is returned over that 
connection. When a problem occurs in a message sent using the SCCP connectionless service, the error message is 
returned using the SCCP connectionless service. 

To avoid overload of the A-interface, transmission of error messages may be inhibited. (However, the transmission of 
Assignment Failure, Handover Failure, Handover Required Reject and Cipher Mode Reject messages in the cases 
required by 3.1.1, 3.1.5 and 3.1.14 shall not be inhibited.) When the transmission of error messages is inhibited, they shall 
be replaced by some kind of notification to O&M. Several settings may be used to allow various subsets of 'error events' 
to trigger error messages while the remaining events only lead to O&M notification. 

The Error pointer in the Diagnostics information element should be used to indicate the position of a detected error in the 
received message. Typical Causes are: 

Cause Usage 

Invalid cell Indicated cell not controlled by the 

BSS or not reachable through the MSC. 

Invalid message contents May be used in any error message. 

Protocol error between BSS The received message is not 

and MSC consistent with the receiver's 

state, or the message has been 

sent in the wrong direction, or 
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the message uses the wrong SCCP 
service (connection oriented 
instead of connectionless or 
vice versa). 



Information element or 
field missing 

Incorrect value 



Unknown message type 



Unknown information element 



Data missing from the area 
indicated by the error pointer. 

A field (that should be 
indicated by the error pointer) 
contains an incorrect or 
incompatible value, or uses a 
reserved codepoint. 

The received message was of an 
unknown type. 

An information element identifier 
(that should be indicated by the 
error pointer) contains an 
unknown value. 



3.1 .1 9.6 Unequipped Circuit Identification Code 

If a MSC or BSS receives a message indicating one or more circuit which are unknown the following actions shall be 
taken: 

- If an ASSIGNMENT REQUEST, a VGCSA^BS ASSIGNMENT REQUEST or a HANDOVER REQUEST 
message is received containing a circuit identity code which is unknown to the BSS the appropriate failure 
message is returned to the MSC. In addition the UNEQUIPPED CIRCUIT message is sent to the MSC for the 
circuit concerned. 

- If an ASSIGNMENT COMPLETE, a VGCSA^BS ASSIGNMENT RESULT, a HANDOVER REQUEST 
ACKNOWLEDGE or a CHANGE CIRCUIT ACKNOWLEDGE Message is received containing a circuit identity 
code which is unknown to the MSC, it is up to the MSC to correct the situation, e.g. by performing a circuit re- 
selection procedure and sending an UNEQUIPPED CIRCUIT Message to the BSS. 

If a circuit supervision message (BLOCK, UNBLOCK or RESET CIRCUIT) is received containing a circuit 
identity code which is not known no respective acknowledgement is returned. Instead an UNEQUIPPED CIRCUIT 
Message is sent to the peer entity for the circuit concerned. 

- If a circuit supervision acknowledgement message (BLOCKING ACKNOWLEDGE, UNBLOCKING 
ACKNOWLEDGE or RESET CIRCUIT ACKNOWLEDGE) is received containing a circuit identity code which 
is not known, an UNEQUIPPED CIRCUIT message is sent to the peer entity for the circuit concerned. 

If a circuit group supervision message (GROUP BLOCK, GROUP UNBLOCK) is received which affects one or 
more circuits which are unknown to the own entity the returned acknowledgement message shall not contain any 
information about these circuit(s), i.e. the respective status bit(s) in the status field shall not be set. Instead an 
UNEQUIPPED CIRCUIT Message is sent to the peer entity for the circuit(s) concerned. 

- If a circuit group supervision acknowledgement message (CIRCUIT GROUP BLOCKING ACKNOWLEDGE or 
CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE) is received which affects one or more circuits which are 
unknown to the own entity an UNEQUIPPED CIRCUIT message is sent to the peer entity for the circuit(s) 
concerned. 

If an UNEQUIPPED CIRCUIT Message is received indicating a circuit which is unknown in the own entity no 
UNEQUIPPED CIRCUIT Message will be returned. 

If an UNEQUIPPED CIRCUIT Message is received indicating a circuit(s) that is known to the recipient, the indicated 
circuit(s) should be removed from service and the situation should be reported to the maintenance system for further 
intervention. The UNEQUIPPED CIRCUIT message is not to be acknowledged by the recipient. 



ETSI 



GSM 08.08 version 6.2.0 Release 1 997 40 TS 1 00 590 V6.2.0 (1 998-1 1 ) 

3.1.19.7 Field Elements 

This section defines the generic error handling to be applied to the field elements found in the "Old BSS to new BSS 
information" information element. 

All field elements shall be treated as non-essential. 

The following events shall not be regarded as errors by the recipient: 

1 spare bits with an unexpected value in any field element; 

2 the use of additional octets in any field element; 

3 a missing field element; 

5 a field element whose length is either too short or too long 

When the recipient detects one or more of these events the receiving entity shall ignore the information that it is unable to 
understand and treat the message on the basis of the information that remains. 

Additionally, 

When an unknown field element identifier is encountered, the unknown field element shall be skipped and 
the receiver shall continue processing any remaining field elements; 



and. 



and. 



when more field elements of a particular type are received than are expected, the last one(s) shall be 
ignored; 



when a sub-field in a field element contains a value, which the recipient knows to be incorrect, the 
recipient shall either ignore that sub-field or ignore the entire field (treating it as if the field element had not 
been received). 



and. 



when a sub-field in a field element contains a reserved value, the recipient shall ignore the entire field 
element (treating it as if the field element had not been received). 

3.1.20 Load Indication Procedure 

The purpose of the load indication procedure is to inform all neighbour BSS's about the traffic situation of a cell. 

The philosophy is to control the incoming handover traffic at the source, i.e. the BSS of the concerned cell informs all of 
its neighbour BSS's about the load situation. This is achieved by sending a LOAD INDICATION message to the neighbour 
BSS's. On receipt of the LOAD INDICATION message the BSS may analyse the load information and take the traffic load 
into consideration when deciding a handover. 

The algorithm in which the BSS decides on starting a Load Indication procedure is operator dependent. 

The implementation of the Load Indication procedure shall be regarded as optional, that means, if this procedure is not 
used, the Load Indication message may be ignored by these network elements. 

3.1 .20.1 Operation of the procedure 

The procedure operates as follows: 

The BSS shall send the LOAD INDICATION message to the MSC with the following information: 

Cell Identifier of the cell where the traffic load situation takes place (Cell Identifier information element). 

The Time indication information element contains the time where the traffic load information shall be valid on the 
receiving side. 
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The Cell identifier list information element contains the cell identifier of the affected neighbour cells. 

The information about the total number of channels accessible or in use, and the information about the current 
number of channels available for each reported channel type on the indicated cell (Resource situation information 
element). 

The reason for sending this message (Cause information element). 

On receipt of the LOAD INDICATION message, the MSC transmits this message to all BSS's as derived from the Cell 
identifier list Information Element. 

NOTE: In the case where more than one indicated cells in the cell identifier list IE belong to the same BSS, the 
MSC should try to send the LOAD INDICATION message only once to this BSS. 

With each reception of a LOAD INDICATION message from the MSC the target BSS shall analyse the resource 
information and adapt the handover traffic either from all cells of the BSS-area or only from the cells contained in the Cell 
identifier list Information Element to the cell indicated in the Cell identifier Information Element. The BSS shall ignore all 
Cell identifiers for cells which do not belong to its area. 

In the case where the BSS receives a LOAD INDICATION message without the Resource situation information element, 
that means the indicated cell is not able to perform incoming handover requests and the receiving BSS may stop the whole 
handover traffic to this cell. 

The traffic load information shall only be valid the time as indicated in the Time indication Information Element. The 
control timer shall be stopped with the receipt of a new LOAD INDICATION message and restarted with the new value. 
If the Time field contains the value 0, the load information is no longer valid. 

3.1 .21 Voice group call service and voice broadcast service call set-up and 
resource assignment 

To set-up a VGCSA^BS call the MSC initiates the VGCS/VBS set-up procedure to the BSS. The MSC can then allocate 
resources to the VGCS/VBS call by initiating the VGCSA'BS Assignment procedure. 

3.1 .21 .1 Successful operation 

To initiate a VGCSA^BS call set-up procedures the MSC sends to the BSS a VGCSA'BS SETUP message across 
VGCSA^BS call controlling SCCP connection. This connection is established for the life time of the VGCSA^BS call. 

The BSS allocates resources to the call and returns VGCSA^BS SETUP ACK message to the MSC. 

3.1 .21 .2 VGCS/VBS call set-up abnormal cases 

If the BSS detects that the VGCS/VBS call is already set-up it will clear all resources associated with the previous call 
and proceed with the new call. 

3.1 .21 .3 VGCS/VBS call set-up failure 

If the BSS can not set-up the VGCS/VBS call then it will send an VGCS/VBS SETUP REFUSE message to the MSC. 

3.1 .22 Voice group call service and voice broadcast service Assignment 
procedure 

The purpose of the VGCS/VBS Assignment procedure is to ensure that the correct dedicated radio resources are allocated 
to the VGCS/VBS call on a per cell basis. The VGCS/VBS Assignment procedure is performed on a VGCS/VBS resource 
controlling SCCP connection. 

The MSC can command that the resources are either allocated immediately or delayed. 
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3.1.22.1 Successful operation 

It is assumed that the VGCSA'BS controHing SCCP connection and the VGCS/VBS resource controlHng SCCP 
connection(s) have been set-up before the VGCS/VBS Assignment procedure takes place. 

The MSC initiates the VGCSA^BS Assignment procedure to the BSS by sending an VGCSA^BS ASSIGNMENT 
REQUEST on a VGCSA^BS resource controlling SCCP connection. 

The BSS will return VGCSA^BS ASSIGNMENT RESULT to the MSC to inform the MSC of the resources allocated by 
the BSS for the concerned cell. 

The BSS shall initiate the radio interface notification procedure on the NCH of the cell in which the call is to take place, 
this may continue at regular intervals until the call is released. The BSS may on SACCH indicate that a change of 
notification has occurred and/or initiate notification on FACCH. 

In the case where the BSS deallocates/allocates resources to the cell, the BSS sends an VGCS/VBS ASSIGNMENT 
RESULT message on the VGCS/VBS resource controlling SCCP connection associated to the cell. 

3.1 .22.2 VGCS/VBS Assignment abnormal cases 

In the abnormal case, where a BSS detects that a voice broadcast or voice group call already exists with the same group 
call reference in a cell (this may occur due to SCCP problems), the BSS shall release the radio resources associated with 
the cell for the present existing voice broadcast or voice group call and shall allocate resources to the new call. 

3.1 .22.3 VGCS/VBS Assignment failure 

In the case were the VGCS/VBS call is unknown by the BSS, the BSS shall return the VGCS/VBS ASSIGNMENT 
FAILURE message (cause "VGCS/VBS call non existent"). 

In the case where no radio resource can be allocated to the VGCS/VBS call, the BSS shall return the VGCS/VBS 
ASSIGNMENT FAILURE message (cause "No radio resource available"). 

3.1.23 Spare 

3.1 .24 Voice group call uplink control procedure 

In the case of voice group calls the uplink resource allocated to the call is controlled by the uplink control procedure. The 
uplink control procedure uses messages sent on the VGCS/VBS controlling SCCP connection set-up by the VGCS/VBS 
call set-up procedure. 

The procedure is split into three procedures: uplink allocation; uplink release; & uplink seize. 

The uplink allocation is controlled by the BSSs and group call anchor MSC. The BSS controls the uplink access for the 
cells in the group call area which are under its control. The group call anchor MSC controls the uplink access for the 
complete service area. Any allocation of the uplink access by a BSS may be refused later by the group call anchor MSC 
(due to the allocation of the uplink by other BSSs involved in the same voice group call). 

The uplink release & uplink seize procedure is controlled and initiated by the MSC, the BSS obeys the MSC's requests. 

When the voice group call is initially set-up the state of the uplink in each BSS is such that the uplink is seized. The MSC 
will control the state of the uplink in each BSS by use of the uplink release and uplink seize procedures. Before an uplink 
may be allocated by the BSS, the MSC must have released the uplink by initiating the uplink release procedure. 

3.1.24.1 Uplink allocation procedure 

The uplink allocation procedure allows a listening user in a voice group call to talk on the uplink of the TCH dedicated to 
the voice group call in the cell. 

The uplink allocation procedure can only occur once the group call anchor MSC has released the uplink (by use of the 
uplink release procedure). 
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When a mobile relinquishes the uplink or the BSS detects that the MS is no longer connected, the BSS sends to the MSC 
an UPLINK RELEASE INDICATION message cause "Call control" or "Radio interface message failure" respectively, the 
BSS may initiate the radio interface uplink free procedure. 

3.1 .24.1 .1 Successful uplink allocation operation 

On reception of a request to talk, the BSS sends an UPLINK REQUEST message to the MSC. The MSC sends the 
UPLINK REQUEST ACKNOWLEDGE message to confirm to the BSS that the uplink is granted to the requesting MS. 
The MSC also sends to all the other BSSs in the voice group call an UPLINK SEIZED COMMAND message. 

The BSS sends UPLINK REQUEST CONHRMATION message with the complete layer information, once the radio link 
has been established. 

3.1 .24.1 .2 Unsuccessful uplink allocation operation 

In the case that the radio link could not be established the BS sends the Uplink release indication with the cause 
"Radiolink interface message failure". 

In the case the MSC does not want to grant the uplink, the MSC will send an UPLINK REJECT COMMAND message to 
the appropriate BSS. On reception of this the BSS will release the uplink for the requesting MS. 

3.1 .24.2 Uplink release procedure 

Once the group call anchor MSC detects that none of the parties involved in a voice group call are talking it will perform 
the uplink release procedure, which will allow the listening subscribers to talk, if the user wishes. To initiate this 
procedure the group call anchor MSC sends the UPLINK RELEASE COMMAND message to each BSS involved in the 
voice group call. When the BSS receives the Uplink release request command, the BSS shall initiate the radio interface 
uplink release procedure. 

3.1 .24.3 Uplink seize procedure 

Once the group call anchor MSC has released the uplink it may detect speech on dedicated channel(s), in this case the 
MSC will send to all BSSs involved in the voice group call an Uplink release command message. On reception of the 
uplink release command message the BSS will initiate the radio interface uplink busy procedure. 

3.1.25 PDSS1 flow control 

The purpose of the PDSS 1 flow control procedure is to inform the MSC that it should stop or resume transmission of 
PDSSl data on this particular transaction. 

The BSS may on the relevant SCCP connection associated with an MS transaction send a SUSPEND message to the MSC 
to ask the MSC not to transmit DTAP messages carrying air interface layer 3 messages of the PDSSl protocol. A typical 
reason is that too many messages are scheduled for transmission on the air interface. 

The BSS may on the relevant SCCP connection associated with an MS transaction send a RESUME message to the MSC 
to indicate to the MSC that DTAP messages carrying air interface layer 3 messages of the PDSSl protocol may be 
transmitted (the typical reason is that congestion on the air interface signalling channel does no more exist). 

3.1 .26 Circuit re-selection procedure 

This procedure has to be supported by a BSS if and only if it allocates the A interface circuits. 

The MSC can request the BSS to change the circuit allocated to a connection by sending a CHANGE CIRCUIT message to 
the BSS on the corresponding SCCP connection. The MSC releases the allocated circuit at the sending of the CHANGE 
CIRCUIT message. 

The MSC shall not start the circuit re-selection procedure if another procedure is on-going that may result in the change of 
the circuit (e.g., circuit re-selection, handover or clearing). 

At the reception of a CHANGE CIRCUIT message, and if the BSS is not already engaged in a procedure that normally 
results in the release of the allocated circuit (e.g., handover or clearing), the BSS allocates a new circuit and indicates it 
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in CHANGE CIRCUIT ACKNOWLEDGE message sent back to the MSC. The BSS releases the previously allocated 
circuit after the sending of the CHANGE CIRCUIT ACKNOWLEDGE message. 

If the MSC receives a message from the BSS indicating the start of a procedure that may result in the change of the circuit 
(e.g., reception of HANDOVER REQUIRED or CLEAR REQUEST), the MSC shall abort the circuit re-selection 
procedure. 

The MSC may not be able to use the terrestrial resource that the BSS has indicated. In this case, the procedure is 
nevertheless considered terminated successfully, and it is up to the MSC to correct the situation, e.g., by a new circuit re- 
selection procedure. 

3.2 Message Formats and Coding 

This subclause defines the coding and format of the messages required for the BSSMAP. 

For each message there is, in subclause 3.2.1, a table listing the signalling elements in their order of appearance in the 
transmitted message. 

There is no general rule for the order of signalling elements: it happens that the same elements appear in various orders 
depending on the message. 
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All the BSSMAP messages are listed in the following table: 



Message name 


Reference 


ASSIGNMENT REQUEST 


3.2.1.1 


ASSIGNMENT COMPLETE 


3.2.1.2 


ASSIGNMENT FAILURE 


3.2.1.3 


BLOCK 


3.2.1.4 


BLOCKING ACKNOWLEDGE 


3.2.1.5 


CIRCUIT GROUP BLOCK 


3.2.1.41 


CIRCUIT GROUP BLOCKING ACKNOWLEDGE 


3.2.1.42 


CIRCUIT GROUP UNBLOCK 


3.2.1.43 


CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE 


3.2.1.44 


CLEAR COMMAND 


3.2.1.21 


CLEAR COMPLETE 


3.2.1.22 


CLEAR REOUEST 


3.2.1.20 


UNBLOCK 


3.2.1.6 


UNBLOCKING ACK 


3.2.1.7 


HANDOVER CANDIDATE ENQUIRE 


3.2.1.14 


HANDOVER CANDIDATE RESPONSE 


3.2.1.15 


HANDOVER REQUEST 


3.2.1.8 


HANDOVER REQUIRED 


3.2.1.9 


HANDOVER REQUIRED REJECT 


3.2.1.37 


HANDOVER REQUEST ACKNOWLEDGE 


3.2.1.10 


HANDOVER COMMAND 


3.2.1.11 


HANDOVER COMPLb lb 


3.2.1.12 


HANDOVER SUCCEEDED 


3.2.1.13 


HANDOVER FAILURE 


3.2.1.16 


HANDOVER PERFORMED 


3.2.1.25 


HANDOVER DETECT 


3.2.1.40 


RESOURCE REQUEST 


3.2.1.17 


RESET 


3.2.1.23 


RESET ACK 


3.2.1.24 


RESOURCE INDICATION 


3.2.1.18 


PAGING 


3.2.1.19 


OVERLOAD 


3.2.1.26 


MSC INVOKE TRACE 


3.2.1.27 


BSS INVOKE TRACE 


3.2.1.28 


CLASSMARK UPDATE 


3.2.1.29 


CLASSMARK REQUEST 


3.2.1.46 


CIPHER MODE COMMAND 


3.2.1.30 


CIPHER MODE COMPLETE 


3.2.1.31 


CIPHER MODE REJECT 


3.2.1.48 


COMPLETE LAYER 3 INFORMATION 


3.2.1.32 


QUEUING INDICATION 


3.2.1.33 


SAPI 'N" REJECT 


3.2.1.34 


RESET CIRCUIT 


3.2.1.38 


RESET CIRCUIT ACKNOWLEDGE 


3.2.1.39 


CONFUSION 


3.2.1.45 


UNEQUIPPED CIRCUIT 


3.2.1.47 


LOAD INDICATION 


3.2.1.49 


VGCS/VBS SETUP 


3.2.1.50 


VGCS/VBS SETUP ACK 


3.2.1.51 


VGCS/VBS SETUP REFUSE 


3.2.1.52 


VGCS/VBS ASSIGNMENT REQUEST 


3.2.1.53 


VGCS/VBS ASSIGNMENT RESULT 


3.2.1.54 


VGCS/VBS ASSIGNMENT FAILURE 


3.2.1.55 


VGCS/VBS QUEUING INDICATION 


3.2.1.56 


(continued) 
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(concluded): 



Message name 


Reference 


UPLINK REQUEST 


3.2.1.57 


UPLINK REQUEST ACKNQWLEDGE 


3.2.1.58 


UPLINK REQUEST CONFIRMATIQN 


3.2.1.59 


UPLINK RELEASE INDICATIQN 


3.2.1.60 


UPLINK REJECT CQMMAND 


3.2.1.61 


UPLINK RELEASE CQMMAND 


3.2.1.62 


UPLINK SEIZED COMMAND 


3.2.1.63 


SUSPEND 


3.2.1.64 


RESUME 


3.2.1.65 


CHANGE CIRCUIT 


3.2.1.66 


CHANGE CIRCUIT ACKNQWLEDGE 


3.2.1.67 



3.2.1 Message Contents 



3.2.1.1 



ASSIGNMENT REQUEST 



This message is sent from the MSC to the BSS via the relevant SCCP connection in order to request the BSS to assign 
radio resource(s), the attributes of which are defined within the message. 

The message may also include the terrestrial circuit to be used. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 


Channel Type 


3.2.2.11 


MSC-BSS 


M 


5-10 


Layer 3 Header Information 


3.2.2.9 


MSC-BSS 


0(3) 


4 


Priority 


3.2.2.18 


MSC-BSS 


Q 


3 


Circuit Identity Code 


3.2.2.2 


MSC-BSS 


0(1) 


3 


Downlinl< DTX Flag 


3.2.2.26 


MSC-BSS 


0(2) 


2 


Interference Band To Be Used 


3.2.2.21 


MSC-BSS 


Q 


2 


Classmark Information 2 


3.2.2.19 


MSC-BSS 


0(4) 


4-5 


Group Call Reference 


3.2.2.55 


MSC-BSS 


0(5) 


3-8 


Talker Flag 


3.2.2.54 


MSC-BSS 


0(6) 


1 


Configuration Evolution Indication 


3.2.2.57 


MSC-BSS 


0(7) 


2 



1 This element is included when the MSC allocates the A interface circuits and the channel type Information 
Element indicates speech or data, and only in those cases. 

2 This element may be included in the case of a speech TCH, and only in this case. If not included, this has no 
impact on the DTX function in the BSS. 

3 This information element doesn't serve any useful purpose. MSCs should not send the information element 
unless it is required by the recipients (due to the need to interwork with older versions of the protocol). It is 
expected that in future versions of 08.08, this information element will be deleted from this message. 

4 These elements may be included if the information is known by the MSC. 

5 This may be included by the MSC for either a talking or listening subscriber in a group call. 

6 This information element is included for group calls, when this is included it indicates that the mobile is a 
talker in the call else the mobile is a listener. 

7 The information is indicated by the MSC if known 
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3.2.1.2 ASSIGNMENT COMPLETE 

The ASSIGNMENT COMPLETE message is sent from the BSS to the MSC and indicates that the requested assignment 
has been completed correctly. 

The message is sent via the BSSAP SCCP connection associated with the dedicated resource(s). 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


RR Cause 


3.2.2.22 


BSS-MSC 





2 


Circuit Identity Code 


3.2.2.2 


BSS-MSC 


0(4) 


3 


Cell Identifier 


3.2.2.17 


BSS-MSC 


0(1) 


3-10 


Chosen Channel 


3.2.2.33 


BSS-MSC 


0(3) 


2 


Chosen Encryption Algorithm 


3.2.2.44 


BSS-MSC 


0(5) 


2 


Circuit Pool 


3.2.2.45 


BSS-MSC 


0(2) 


2 


Speech Version (Chosen) 


3.2.2.51 


BSS-MSC 


0(6) 


2 



1 The cell identifier is used to indicate a new cell, if during the assignment the serving cell has changed. 

2 Shall be included when several circuit pools are present on the BSS MSC interface and a circuit was 
allocated by the ASSIGNMENT REQUEST message. 

3 Included at least when the channel rate/type choice was done by the BSS. 

4 The Circuit Identity Code information element is included mandatorily by the BSS if the BSS allocates the 
A interface circuits and a circuit is needed. 

5 Included at least when the encryption algorithm has been changed by the BSS. 

6 Included at least when the speech version choice was done by the BSS. 

3.2.1.3 ASSIGNMENT FAILURE 

The ASSIGNMENT FAILURE message is sent from the BSS to the MSC via the relevant SCCP connection. It indicates 
that there has been a failure in the assignment process at the BSS and that the assignment procedure has been aborted. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


Cause 


3.2.2.5 


BSS-MSC 


M 


3-4 


RR Cause 


3.2.2.22 


BSS-MSC 





2 


Circuit Pool 


3.2.2.45 


BSS-MSC 


0(1) 


2 


Circuit Pool List 


3.2.2.46 


BSS-MSC 


0(2) 


V 



1 Shall be included when several circuit pools are present on the BSS MSC interface. 

2 May be included when cause is "circuit pool mismatch" or "switch circuit pool" to indicate circuit pool 
preferences. 
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Typical Cause values are: 

radio interface message failure, 

O and M intervention, 

equipment failure, 

no radio resource available, 

requested terrestrial resource unavailable, 

requested transcoding/rate adaption unavailable, 

terrestrial resource already allocated, 

invalid message contents, 

radio interface failure - reversion to old channel, 

directed retry, 

circuit pool mismatch, 

switch circuit pool. 

requested speech version unavailable. 



3.2.1.4 



BLOCK 



This message is sent from the BSS to the MSC or from the MSC to the BSS to indicate that a particular terrestrial resource 
(i.e. a particular timeslot within a 2Mbit system) must be remotely blocked at the circuit master, and cannot therefore be 
used for traffic. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


both 


M 


1 


Circuit Identity Code 


3.2.2.2 


both 


M 


3 


Cause 


3.2.2.5 


both 


M 


3-4 


Connection Release Requested 


3.2.2.3 


MSC-BSS 





1 



Typical Cause values are: 

no radio resource available, 
O and M intervention, 
equipment failure. 



3.2.1.5 



BLOCKING ACKNOWLEDGE 



This message is sent from the MSC to the BSS or from the BSS to the MSC to acknowledge the receipt of an earlier 
BLOCK message, and to indicate that the circuit concerned has been removed from service. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Circuit Identity Code 


3.2.2.1 
3.2.2.2 


both 
both 


M 
M 


1 
3 
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3.2.1.6 



UNBLOCK 



This message is sent from the BSS to the MSC or from the MSC to the BSS to indicate that a particular terrestrial resource 
(ie a particular timeslot within a 2Mbit system) should not be remotely blocked any more on the receiver side. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Circuit Identity Code 


3.2.2.1 
3.2.2.2 


both 
both 


M 
M 


1 
3 



3.2.1.7 



UNBLOCKING ACKNOWLEDGE 



This message is sent from the MSC to the BSS or from the BSS to the MSC to acknowledge the receipt of an earlier 
UNBLOCK message. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Circuit Identity Code 


3.2.2.1 
3.2.2.2 


both 
both 


M 
M 


1 
3 



3.2.1.8 



HANDOVER REOUEST 



This message is sent from the MSC to the BSS via the relevant SCCP connection to indicate that the MS is to be handed 
over to that BSS. 
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INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 


Channel Type 


3.2.2.11 


MSC-BSS 


M 


5-10 


Encryption Information 


3.2.2.10 


MSC-BSS 


M(1) 


3-n 


Classmark Information 1 Or 
Classmark Information 2 


3.2.2.30 
3.2.2.19 


MSC-BSS 
MSC-BSS 


M# 
M(6) 


2 
4-5 


Cell Identifier (Serving) 


3.2.2.17 


MSC-BSS 


M 


5-10 


Priority 


3.2.2.18 


MSC-BSS 





3 


Circuit Identity Code 


3.2.2.2 


MSC-BSS 


0(7) 


3 


Downlink DTX Flag 


3.2.2.26 


MSC-BSS 


0(3) 


2 


Cell Identifier (Target) 


3.2.2.17 


MSC-BSS 


M 


3-10 


Interference Band To Be Used 


3.2.2.21 


MSC-BSS 





2 


Cause 


3.2.2.5 


MSC-BSS 


0(9) 


3-4 


Classmark Information 3 


3.2.2.20 


MSC-BSS 


0(4) 


3-14 


Current Channel Type 1 


3.2.2.49 


MSC-BSS 


0(8) 


2 


Speech Version (Used) 


3.2.2.51 


MSC-BSS 


0(10) 


2 


Group Call Reference 


3.2.2.55 


MSC-BSS 


0(5) 


3-8 


Talker Flag 


3.2.2.54 


MSC-BSS 


0(11) 


1 


Configuration Evolution Indication 


3.2.2.57 


MSC-BSS 


0(12) 


2 


Chosen Encryption Algorithm 
(Serving) 


3.2.2.44 


MSC-BSS 


0(2) 


2 


Old BSS to New BSS Information 


3.2.2.59 


MSC-BSS 


0(13) 


2-n 



1 If the MSC has not sent a CIPHER MODE COMMAND for this RR connection (or has had all such 
CIPHER MODE COMMANDS rejected with CIPHER MODE REJECT messages) then the MSC shall 
indicate that the only "permitted algorithm" is "no encryption". 

2 If this information element is included, it shall be equal to the last received "Chosen Encryption Algorithm" 
information element. 

3 This element may be included in the case of a speech TCH, and only in this case. If not included, this has no 
impact on the DTX function in the BSS. 

4 This element is included if the MSC has received such information. 

5 This element is included if the MS is in a voice broadcast or voice group call. 

6 One of these two elements is sent. 

7 This element is included when the channel type Information Element indicates speech or data, and only in 
those cases. 

8 This element is included at least when the message is sent as a reaction to reception of a HANDOVER 
REQUIRED message containing a "Current channel Type 1" information element. In this case it shall be 
equal to the received element. 
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9 This information element should always be included. Its cause value should be the same as indicated in the 
corresponding Handover Required message. 

10 This element is included at least when the message is sent as a reaction to reception of a HANDOVER 
REQUIRED message containing a "Speech version (used)" information element. In this case it shall be 
equal to the received element. 

1 1 This information element is included for voice group call, when this is included it indicates that the mobile 
is a talker in the call else the mobile is a listener. 

12 The information is indicated by the MSC if known 

13 This element is included if and only if the message is sent as a reaction to the reception of a HANDOVER 
REQUIRED message containing an "old BSS to new BSS information" information element. Its contents 
shall be equal to the received element. 



Typical Cause values are: 

uplink quality, 

uplink strength, 

downlink quality, 

downlink strength 

distance, 

better cell, 

response to MSC invocation 

O and M intervention, 

directed retry, 

switch circuit pool, 

traffic, 

preemption. 



3.2.1.9 



HANDOVER REQUIRED 



This message is sent from the BSS to the MSC to indicate that for a given MS which already has dedicated radio 
resource(s) assigned, a handover is required for the reason given by the cause element. 

The message is sent via the BSSAP SCCP connection associated with the dedicated resource(s). 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


Cause 


3.2.2.5 


BSS-MSC 


M 


3-4 


Response Request 


3.2.2.28 


BSS-MSC 





1 


Cell Identifier List 
(Preferred) 


3.2.2.27 


BSS-MSC 


M 


2n+3 

to 
7n-H3 


Circuit Pool List 


3.2.2.46 


BSS-MSC 


0(1) 


V 


Current Channel Type 1 


3.2.2.49 


BSS-MSC 


0(2) 


2 


Speech Version (Used) 


3.2.2.51 


BSS-MSC 


0(3) 


2 


Queueing Indicator 


3.2.2.50 


BSS-MSC 





2 


Old BSS to New BSS Information 


3.2.2.59 


BSS-MSC 





2-n 



Shall be included when cause "switch circuit pool" and the MSC allocates the A interface circuit. 
This information element should always be included. 
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3 This information element should always be included when the channel mode is speech, and only in this 

case. 

Typical Cause values are: 

uplink quality, 

uplink strength, 

downlink quality, 

downlink strength, 

distance, 

better cell, 

response to MSC invocation, 

O&M intervention, 

directed retry, 

switch circuit pool, 

traffic, 

preemption. 



3.2.1.10 



HANDOVER REQUEST ACKNOWLEDGE 



This message is sent from the BSS to the MSC and indicates that the request to support a handover at the target BSS can 
be supported by the BSS, and also to which radio channel(s) the MS should be directed. 

The message is sent via the BSSAP SCCP connection associated with the dedicated resource. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


Layers Information 


3.2.2.24 


BSS-MSC 


M (1) 


11-n 


Chosen Channel 


3.2.2.33 


BSS-MSC 


0(4) 


2 


Chosen Encryption Algorithm 


3.2.2.44 


BSS-MSC 


0(5) 


2 


Circuit Pool 


3.2.2.45 


BSS-MSC 


0(2) 


2 


Speech Version (Chosen) 


3.2.2.51 


BSS-MSC 


0(6) 


2 


Circuit Identity Code 


3.2.2.2 


BSS-MSC 


0(3) 


3 



1 This information field carries a radio interface HANDOVER COMMAND message. 

2 Shall be included when several circuit pools are present on the BSS MSC interface and a circuit was 
allocated by the HANDOVER REQUEST message. 

3 The Circuit identity code information element is included mandatorily by the BSS if the BSS allocates the A 
interface circuits and a circuit is needed. 

4 Included at least when the channel rate/type choice was done by the BSS. 

5 Included at least when the encryption algorithm has been selected by the BSS. 

6 Included at least when the speech version choice was done by the BSS. 
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3.2.1.11 



HANDOVER COMMAND 



This message is sent from the MSC to the BSS via the relevant SCCP connection and contains the target channel to which 
the MS should retune. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 


Layer 3 Information 


3.2.2.24 


MSC-BSS 


M(1) 


11-n 


Cell Identifier 


3.2.2.17 


MSC-BSS 





3-10 



1 This information field carries a radio interface HANDOVER COMMAND message. 

3.2.1.12 HANDOVER COMPLETE 

This message is sent from the BSS to the MSC via the relevant SCCP connection. 
It indicates that the correct MS has successfully accessed the target cell. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
RR Cause 


3.2.2.1 
3.2.2.22 


BSS-MSC 
BSS-MSC 


M 



1 
2 



3.2.1.13 HANDOVER SUCCEEDED 

This message is sent from the MSC to the old BSS via the relevant SCCP connection. 
It indicates that the correct MS has successfully accessed the target cell. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 



3.2.1.14 HANDOVER CANDIDATE ENOUIRE 

This message is sent from the MSC to the BSS, using the connectionless services of the SCCP. 
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INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 


Number Of Mss 


3.2.2.8 


MSC-BSS 


M 


2 


Cell Identifier List 


3.2.2.27 


MSC-BSS 


M 


2n+3 

to 
7n-i-3 










Cell Identifier 


3.2.2.17 


MSC-BSS 


M 


3-10 



3.2.1.15 



HANDOVER CANDIDATE RESPONSE 



This message is sent from the BSS to the MSC in response to receipt of a HANDOVER CANDIDATE ENQUIRE 
message. It contains the number of MSs for which HANDOVER REQUIRED messages have been sent. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


Number Of Mss 


3.2.2.8 


BSS-MSC 


M 


2 


Cell Identifier 


3.2.2.17 


BSS-MSC 


M 


3-10 



3.2.1.16 



HANDOVER FAILURE 



This message is sent from the BSS to the MSC via the relevant SCCP connection. It indicates to the MSC that there has 
been a failure in the resource allocation process on handover, and that the handover has been aborted. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


Cause 


3.2.2.5 


BSS-MSC 


M 


3-4 


RR Cause 


3.2.2.22 


BSS-MSC 





2 


Circuit Pool 


3.2.2.45 


BSS-MSC 


0(1) 


2 


Circuit Pool List 


3.2.2.46 


BSS-MSC 


0(2) 


V 



1 Shall be included when several circuit pools are present on the BSS MSC interface. 

2 May be included when cause is "circuit pool mismatch" or "switch circuit pool" to indicate circuit pool 
preferences. 

Typical Cause values are: 

radio interface message failure; 

O and M intervention; 

Equipment failure; 

no radio resource available; 

requested terrestrial resource unavailable; 

requested transcoding/rate adaption unavailable; 

terrestrial resource already allocated; 

invalid message contents; 

radio interface failure - reversion to old channel; 

ciphering algorithm not supported; 

circuit pool mismatch; 

switch circuit pool; 

requested speech version unavailable. 
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3.2.1.17 



RESOURCE REQUEST 



This message is sent from the MSC to the BSS and requests the current spare and optionally the total accessible resource 
on a particular cell. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 


Periodicity 


3.2.2.12 


MSC-BSS 


M 


2 


Resource Indication Method 


3.2.2.29 


MSC-BSS 


M 


2 


Cell Identifier 


3.2.2.17 


MSC-BSS 


M 


3-10 


Extended Resource Indicator 


3.2.2.13 


MSC-BSS 





2 



3.2.1.18 



RESOURCE INDICATION 



This message is sent from the BSS to the MSC in response to a resource request message, the message includes an explicit 
indication of the cell concerned. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


Resource Indication Method 


3.2.2.29 


BSS-MSC 


M 


2 


Resource Available 


3.2.2.4 


BSS-MSC 


0(1) 


21 


Cell Identifier 


3.2.2.17 


BSS-MSC 


M 


3-10 


Total Resource Accessible 


3.2.2.14 


BSS-MSC 


0(2) 


5 



1 This element is not included if the message is sent only as an acknowledgement to the reception of a 
RESOURCE REQUEST message. 

2 This element has to be included if requested by the Extended Resource Indicator, except when the message 
is sent only as an acknowledgement to the reception of the RESOURCE REQUEST message. 
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3.2.1.19 



PAGING 



This message is sent from the MSC to the BSS and contains sufficient information to allow the paging message to be 
transmitted by the correct cells at the correct time. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 


IMSI 


3.2.2.6 


MSC-BSS 


M 


3-10 


TMSI 


3.2.2.7 


MSC-BSS 


0(1) 


6 


Cell Identifier List 


3.2.2.27 


MSC-BSS 


M 


3 to 
3-^7n 


Channel Needed 


3.2.2.36 


MSC-BSS 


0(2) 


2 


eMLPP Priority 


3.2.2.56 


MSC-BSS 


0(3) 


2 



1 This element is omitted in the exceptional case where the IMSI is used instead of the TMSI as a paging 
address at the radio interface. 

2 If the channel needed element is not present, the default value is assumed to be 00 (any channel). 

3 If the BSS implements the eMLPP feature it should use this information element to build the radio interface 
Paging request messages, otherwise the information may be considered as an unrecognisable information 
element. 



3.2.1.20 



CLEAR REQUEST 



This message is sent from the BSS to the MSC to indicate to the MSC that the BSS wishes to release the associated 
dedicated resource(s). 

The message is sent via the BSSAP SCCP connection associated with the dedicated resource(s). 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Cause 


3.2.2.1 
3.2.2.5 


BSS-MSC 
BSS-MSC 


M 
M 


1 

3-4 
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Typical Cause values are: 

radio interface message failure, 

O and M intervention, 

equipment failure. 

Joined group call channel, 

protocol error between BSS and MSC, 

preemption. 

3.2.1.21 CLEAR COMMAND 

This message is sent from the MSC to the BSS to instruct the BSS to release the associated dedicated resource(s). 
The message is sent via the BSSAP SCCP connection associated with the dedicated resource(s). 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 


Layer 3 Header Information 


3.2.2.9 


MSC-BSS 


0(1) 


4 


Cause 


3.2.2.5 


MSC-BSS 


M 


3-4 



1 This information element doesn't serve any useful purpose. MSCs should not send the information element 
unless it is required by the recipients (due to the need to interwork with older versions of the protocol). It is 
expected that in future versions of 08.08, this information element will be deleted from this message. 

Typical Cause values are: 
call control, 
O and M intervention, 
equipment failure, 
handover successful, 
protocol error between BSS and MSC. 



3.2.1.22 



CLEAR COMPLETE 



This message is sent from the BSS to the MSC to inform the MSC that the associated dedicated resource(s) has been 
successfully cleared. 

The message is sent via the BSSAP SCCP connection associated with the dedicated resource(s). 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 



3.2.1.23 



RESET 



This message can be sent either from the BSS to the MSC or from the MSC to the BSS. It indicates to the receiving entity 
that the transmitting entity has suffered a failure and has lost memory of the calls in progress, calls set up, and associated 
references. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Cause 


3.2.2.1 
3.2.2.5 


Both 
Both 


M 
M 


1 
3-4 



Typical Cause values are: 

O and M intervention, 
equipment failure. 
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3.2.1.24 



RESET ACKNOWLEDGE 



This message can be sent either from the BSS to the MSC or from the MSC to the BSS. It indicates to the receiving entity 
that the transmitting entity has cleared all calls and reset all references, and is ready to resume service. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


Both 


M 


1 



3.2.1.25 HANDOVER PERFORMED 

This message is sent from the BSS to the MSC in order to indicate that the BSS has performed an internal handover. 
The cell identifier and (if required for O and M reasons) optionally the new channel identity is included. 
The message is sent via the BSSAP SCCP connection associated with the dedicated resource(s). 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


Cause 


3.2.2.5 


BSS-MSC 


M 


3-4 


Cell Identifier 


3.2.2.17 


BSS-MSC 


M 


3-10 


Chosen Channel 


3.2.2.33 


BSS-MSC 


0(1) 


2 


Chosen Encryption Algorithm 


3.2.2.44 


BSS-MSC 


0(2) 


2 


Speech Version (Chosen) 


3.2.2.51 


BSS-MSC 


0(3) 


2 



1 Included at least when the channel rate/type has changed during the handover. 

2 Included at least when the encryption algorithm has been changed by the BSS. 

3 Included at least when the speech version has been changed by the BSS. 

Typical Cause values: as for the handover required message, except response to MSC invocation. 



3.2.1.26 



OVERLOAD 



This message is sent from the BSS to the MSC or from the MSC to the BSS. When sent from the BSS to the MSC it 
indicates either processor overload of the whole BSS (cell identifier field not present) or overload of a CCCH downlink 
in which case the relevant cell is identified. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


Both 


M 


1 


Cause 


3.2.2.5 


Both 


M 


3-4 


Cell Identifier 


3.2.2.17 


BSS-MSC 





3-10 



Typical Cause values are: 

Processor overload, 
CCCH overload, 
O&M intervention. 
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3.2.1 .27 MSC INVOKE TRACE 

This message is sent from the MSC to the BSS in order to start production of a trace record at the BSS. 
The message is sent via the BSSAP SCCP connection associated with the dedicated resource(s). 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 


Trace Type 


3.2.2.37 


MSC-BSS 


M 


2 


Triggerid 


3.2.2.38 


MSC-BSS 





3-22 


Trace Reference 


3.2.2.39 


MSC-BSS 


M 


3 


Transactionid 


3.2.2.40 


MSC-BSS 





4 


Mobile Identity 


3.2.2.41 


MSC-BSS 





3-10 


OMCId 


3.2.2.42 


MSC-BSS 





3-22 



3.2.1.28 



BSS INVOKE TRACE 



This message is sent from the BSS to the MSC in order to start production of a trace record at the MSC and/or from the 
MSC to BSS to target BSSs after a handover. 

The message is sent via the BSSAP SCCP connection associated with the dedicated resource(s). 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


Both 


M 


1 


Trace Type 


3.2.2.37 


Both 


M 


2 


Forward Indicator 


3.2.2.43 


Both 





2 


Triggerid 


3.2.2.38 


Both 





3-22 


Trace Reference 


3.2.2.39 


Both 


M 


3 


Transactionid 


3.2.2.40 


Both 





4 


OMCId 


3.2.2.42 


Both 





3-22 



3.2.1.29 



CLASSMARK UPDATE 



This message is sent from the BSS to the MSC or from the MSC to the BSS via the relevant SCCP connection associated 
with that MS transaction. It updates the classmark parameters for the concerned MS. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


Both 


M 


1 


Classmarl< Information Type 2 


3.2.2.19 


Both 


M 


4-5 


Classmarl< Information Type 3 


3.2.2.20 


Both 


0(1) 


3-14 



1 This element shall be included by the BSS if it was received from the MS. It shall be included by the MSC 
if this information element has previously been received by the MSC. 
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3.2.1.30 



CIPHER MODE COMMAND 



This message is sent from the MSC to the BSS via the relevant SCCP connection associated with that MS transaction. It 
updates the encryption parameters for the concerned MS. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 


Layers Header Information 


3.2.2.9 


MSC-BSS 


0(1) 


4 


Encryption Information 


3.2.2.10 


MSC-BSS 


M 


3-n 


Cipher Response Mode 


3.2.2.34 


MSC-BSS 





2 



1 This information element doesn't serve any useful purpose. MSCs should not send the information element 
unless it is required by the recipients (due to the need to interwork with older versions of the protocol). It is 
expected that in future versions of 08.08, this information element will be deleted from this message. 

3.2.1 .31 CIPHER MODE COMPLETE 

This message is sent from the BSS to the MSC via the relevant SCCP connection. It indicates that a successful cipher 
synchronisation has been achieved across the radio interface. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


Layer 3 Message Contents 


3.2.2.35 


BSS-MSC 





2-n 


Chosen Encryption Algorithm 


3.2.2.44 


BSS-MSC 


0(1) 


2 



1 Included at least when the encryption algorithm has been selected by the BSS. 



3.2.1.32 



COMPLETE LAYER 3 INFORMATION 



The message is sent from the BSS to the MSC as described in subclause 3.1.16 (on receipt of the initial layer 3 message 
on a dedicated channel, e.g. PAGING RESPONSE, LOCATION UPDATING REQUEST, CM REESTABLISHMENT 
REQUEST, CM SERVICE REQUEST, IMSI DETACH, NOTMCATION RESPONSE, IMMEDIATE SETUP). 

The message is sent via the BSSAP SCCP connection established for the associated dedicated resource(s). 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


Cell Identifier 


3.2.2.17 


BSS-MSC 


M 


3-10 


Layer 3 Information 


3.2.2.24 


BSS-MSC 


M 


3-n 


Chosen Channel 


3.2.2.33 


BSS-MSC 


0(1) 


2 



1 This element is optionally used by the BSS to give the MSC a description of the channel rate/type on which 
the initial layer 3 message was received. 

3.2.1.33 OUEUEING INDICATION 

This message is sent from the BSS to the MSC in order to indicate a delay in the assignment of the required TCH. 
The message is sent via the BSSAP SCCP connection associated with the dedicated resource(s). 
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INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 



3.2.1.34 SAPI "n" REJECT 

This message is sent from the BSS to the MSC in order to indicate that a message with a SAPI value other than "0" has 
been rejected. 

The message is sent via the BSSAP SCCP connection associated with the dedicated resource(s). 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


DLCI 


3.2.2.25 


BSS-MSC 


M 


2 


Cause 


3.2.2.5 


BSS-MSC 


M 


3-4 



Typical Cause values are: 

O&M intervention, 
processor overload, 
BSS not equipped, 
MS not equipped. 



3.2.1.35 



[spare] 



3.2.1.36 



[spare] 



3.2.1.37 



HANDOVER REQUIRED REJECT 



This message is sent from the MSC to the BSS via the relevant SCCP connection. It indicates to the BSS that the 
HANDOVER REQUIRED message has not resulted in handover. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Cause 


3.2.2.1 
3.2.2.5 


MSC-BSS 
MSC-BSS 


M 
M 


1 
3-4 



Typical Cause values are: 

equipment failure, 

no radio resource available, 

requested terrestrial resource unavailable, 

invalid message contents, 

requested transcoding/rate adaptation unavailable, 

O and M intervention. 



3.2.1.38 



RESET CIRCUIT 



This message is sent either from the BSS to the MSC or from the MSC to the BSS. It indicates to the receiving entity that 
the state of the circuit indicated in the message is unknown, due to a failure. 

This message is sent as a SCCP connectionless message. 
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INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


Botli 


M 


1 


Circuit Identity Code 


3.2.2.2 


Botli 


M 


3 


Cause 


3.2.2.5 


Both 


M 


3-4 



Typical Cause values are: as for the RESET message. 



3.2.1.39 



RESET CIRCUIT ACKNOWLEDGE 



This message is sent either from the BSS to the MSC or from the MSC to the BSS. It indicates to the receiving entity that 
the transmitting entity has cleared a possible call using the circuit, and is ready to resume service. 

This message is sent as a connectionless SCCP message. 



3.2.1.40 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Circuit Identity 


3.2.2.1 
3.2.2.2 


Botli 
Both 


M 
M 


1 
3 



HANDOVER DETECT 



This message is sent from the BSS to the MSC via the relevant SCCP connection. It indicates that the correct MS has 
successfully accessed the target cell. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 



3.2.1.41 



CIRCUIT GROUP BLOCK 



This message is sent from the BSS to the MSC or from the MSC to the BSS to indicate that a set of terrestrial resources 
(ie some timeslots within a system of 2Mbit PCM multiplex) must be remotely blocked at the circuit master, and cannot 
therefore be used for traffic. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


both 


M 


1 


Cause 


3.2.2.5 


both 


M 


3-4 


Circuit Identity Code 


3.2.2.2 


both 


M 


3 


Circuit Identity Code List 


3.2.2.31 


both 


M 


4-35 



Typical Cause values: O & M intervention, 
equipment failure. 



3.2.1.42 



CIRCUIT GROUP BLOCKING ACKNOWLEDGE 



This message is sent from the MSC to the BSS or from the BSS to the MSC to acknowledge the receipt of an earlier 
CIRCUIT GROUP BLOCK message, and to indicate that the circuits indicated in the status subfield of the Circuit Identity 
Code List have been remotely blocked. 

This message is sent as a connectionless SCCP message. 
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INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


both 


M 


1 


Circuit Identity Code 


3.2.2.2 


both 


M 


3 


Circuit Identity Code List 


3.2.2.31 


both 


M 


4-35 



3.2.1.43 



CIRCUIT GROUP UNBLOCK 



This message is sent from the BSS to the MSC or from the MSC to the BSS to indicate that a set of terrestrial resources 
(ie some timeslots within a system of 2Mbit PCM muhiplex) may be returned to service at the circuit master. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


both 


M 


1 


Circuit Identity Code 


3.2.2.2 


both 


M 


3 


Circuit Identity Code List 


3.2.2.31 


both 


M 


4-35 



3.2.1.44 



CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE 



This message is sent from the MSC to the BSS or from the MSC to the BSS to acknowledge the receipt of an earlier 
CIRCUIT GROUP UNBLOCK message, and to indicate that the circuits indicated in the status subfield of the Circuit 
Identity Code List are remotely unblocked. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


both 


M 


1 


Circuit Identity Code 


3.2.2.2 


both 


M 


3 


Circuit Identity Code List 


3.2.2.31 


both 


M 


4-35 



3.2.1.45 



CONFUSION 



This message is sent in either direction in response to a message which cannot be treated correctly for some reason, and 
for which another failure message cannot substitute. The use of this message may be under operator control. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


Both 


M 


1 


Cause 


3.2.2.5 


Both 


M 


3-4 


Diagnostics 


3.2.2.32 


Both 


M 


4-n 



Typical Cause values are: 

Invalid message contents; 

information element or field missing; 

incorrect value; 

unknown message type; 

unknown information element; 

protocol error between BSS and MSC; and 

invalid cell. 
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3.2.1.46 



CLASSMARK REQUEST 



This message is sent from the MSC to the BSS via the relevant SCCP connection associated with that MS transaction. It 
requests an update of the classmark parameters for the concerned MS. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 



3.2.1.47 



UNEQUIPPED CIRCUIT 



This message is sent from the BSS to the MSC or vice versa to indicate to the partner entity that it is utilising one or 
several circuit identity codes which are unknown and which therefore should be locally blocked immediately and taken 
out of service. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


Botli 


M 


1 


Circuit Identity Code 


3.2.2.2 


Botli 


M 


3 


Circuit Identity Code List 


3.2.2.31 


Both 





4-35 



3.2.1.48 



CIPHER MQDE REJECT 



This message is sent from the BSS to the MSC via the relevant SCCP connection associated with that MS transaction. It 
indicates that the BSS is unable to perform the requested ciphering. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Cause 


3.2.2.1 
3.2.2.5 


BSS-MSC 
BSS-MSC 


M 
M 


1 
3-4 



Typical Cause values are: 

Ciphering algorithm not supported, 
Invalid message contents 



3.2.1.49 



LQAD INDICATIQN 



The LOAD INDICATION message is sent from the BSS to the MSC and from the MSC to the BSS. It indicates to the 
receiving entity that the transmitting BSS has detected a load situation in the concerned cell. 

This message is sent as a connectionless SCCP message. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


Both 


M 


1 


Time Indication 


3.2.2.47 


Both 


M 


2 


Cell Identifier 


3.2.2.17 


Both 


M 


3-10 


Cell Identifier List (Target) 


3.2.2.27 


Both 


M 


3 to 
3-i-7n 


Resource Situation 


3.2.2.48 


Both 


0(1) 


4-N 


Cause 


3.2.2.5 


Both 


0(2) 


4-5 
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Typical Cause values: 

O & M intervention 
Equipment failure 
No radio resource available 
Processor overload 
Traffic load 

1 This information element can only be omitted, if the sending BSS wants to stop the whole incoming handover 
traffic to the indicated cell. 

2 Included at least when the reason for sending this message is other than traffic load. 



3.2.1.50 



VGCS/VBS SETUP 



This message is sent from the MSC to the BSS via the newly created SCCP connection in order to request the BSS to 
support a VGCSA'BS call. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 


Group Call Reference 


3.2.2.55 


MSC-BSS 


M 


3-8 


Priority 


3.2.2.18 


MSC-BSS 





3 



3.2.1.51 



VGCS/VBS SETUP ACK 



This message is sent from the BSS to the MSC via the newly created SCCP connection in order to confirm that the BSS 
will support the VGCS/VBS call. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 



3.2.1.52 



VGCS/VBS SETUP REFUSE 



This message is sent from the BSS to the MSC via the newly created SCCP connection in order to reject the SETUP of the 
VGCS/VBS call. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Cause 


3.2.2.1 
3.2.2.5 


BSS-MSC 
BSS-MSC 


M 
M 


1 
3-4 



3.2.1.53 



VGCS/VBS ASSIGNMENT REQUEST 



This message is sent from the MSC to the BSS via the newly created VGCS/VBS resource controlling SCCP connection 
in order to request the BSS to assign radio resources in a cell to support a VGCS/VBS call. 
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INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 


Channel Type 


3.2.2.11 


MSC-BSS 


M 


5 


Assignment Requirement 


3.2.2.52 


MSC-BSS 


M 


2 


Cell Identifier 


3.2.2.17 


MSC-BSS 


M 


3-10 


Group Call Reference 


3.2.2.55 


MSC-BSS 


M 


3-8 


Priority 


3.2.2.18 


MSC-BSS 





3 


Circuit Identity Code 


3.2.2.2 


MSC-BSS 





3 


Downlink DTX Flag 


3.2.2.26 


MSC-BSS 





2 


Encryption Information 


3.2.2.10 


MSC-BSS 





3-n 



3.2.1.54 



VGCS/VBS ASSIGNMENT RESULT 



The VGCSA^BS ASSIGNMENT RESULT message when received indicates the assignment/deassignment of radio 
resource for the indicated cell. 

The message is sent by the BSS via the BSSAP VGCSA'^BS resource controlling SCCP connection associated with the 
dedicated resource. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


Channel Type 


3.2.2.11 


BSS-MSC 


M 


5 


Cell Identifier 


3.2.2.17 


BSS-MSC 


M 


3-10 


Chosen Channel 


3.2.2.33 


BSS-MSC 


0(2) 


2 


Circuit Identity Code 


3.2.2.2 


BSS-MSC 





3 


Circuit Pool 


3.2.2.45 


BSS-MSC 


0(1) 


2 



Shall be included when several circuit pools are present on the BSS-MSC interface and a circuit was 
allocated by the ASSIGNMENT REQUEST message. 

Included at least when the channel choice was done by the BSS. 



3.2.1.55 



VGCS/VBS ASSIGNMENT FAILURE 



The VGCSA^BS ASSIGNMENT FAILURE message is sent from the BSS to the MSC via the relevant VGCSA^BS 
resource controlling SCCP connection. It indicates that there has been a failure in an assignment process at the BSS and 
that the VGCSA'BS Assignment procedure has been aborted for the concerned cell. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


Cause 


3.2.2.5 


BSS-MSC 


M 


3-4 


Circuit Pool 


3.2.2.45 


BSS-MSC 


0(1) 


2 


Circuit Pool List 


3.2.2.46 


BSS-MSC 


0(2) 


V 



Shall be included when several circuit pools are present on the BSS-MSC interface. 
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2 May be included when cause is "circuit pool mismatch" or "switch circuit pool" to indicate circuit pool 

preferences. 

Typical Cause values are: 

VGCSA^BS call non existent 

O and M intervention, 

equipment failure, 

no radio resource available, 

requested terrestrial resource unavailable, 

requested transcoding/rate adaptation unavailable, 

terrestrial resource already allocated, 

invalid message contents, 

circuit pool mismatch, 

switch circuit pool, 

ciphering algorithm not supported. 

3.2.1 .56 VGCS/VBS QUEUING INDICATION 

The VGCS/VBS QUEUING INDICATION message is sent from the ESS to the MSC via the relevant VGCSA^BS 
resource controlling SCCP connection. It indicates that there is a delay in the assignment of radio resources for the cell. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 



3.2.1.57 



UPLINK REQUEST 



This message is sent from the BSS to the MSC in order to indicate that a mobile has requested to access the uplink of a 
voice group call channel. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 



3.2.1.58 



UPLINK REQUEST ACKNOWLEDGE 



This message is sent from the MSC to the BSS in order to indicate to the BSS that the uplink allocation of the voice group 
call channel has been granted by the MSC. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


MSC-BSS 


M 


1 
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3.2.1.59 



UPLINK REQUEST CONFIRMATION 



This message is sent from the BSS to the MSC in order to indicate to the MSC that the uplink of the voice group call 
channel has been successfriUy established. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 


3.2.2.1 


BSS-MSC 


M 


1 


Cell Identifier 


3.2.2.17 


BSS-MSC 


M 


3-10 


Layer 3 Information 


3.2.2.24 


BSS-MSC 


M 


3-n 



3.2.1.60 



UPLINK RELEASE INDICATION 



This message is sent from the BSS to the MSC in order to indicate to the MSC that the uplink of the voice group call 
channel has been released. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Cause 


3.2.2.1 
3.2.2.5 


BSS-MSC 
BSS-MSC 


M 
M 


1 
3-4 



Typical cause values 

radio interface message failure 

Call control 

O and M intervention 



3.2.1.61 



UPLINK REJECT COMMAND 



This message is sent from the MSC to the BSS in order to indicate to the BSS that the uplink of the voice group call 
channel is not available for allocation to mobiles that have requested the use of the uplink. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Cause 


3.2.2.1 
3.2.2.5 


MSC-BSS 
MSC-BSS 


M 
M 


1 
3-4 



Typical cause values 

radio interface message failure 

Call control 

O and M intervention 



3.2.1.62 



UPLINK RELEASE COMMAND 



This message is sent from the MSC to the BSS in order to indicate to the BSS that the uplink of the voice group call 
channel is available for allocation. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Cause 


3.2.2.1 
3.2.2.5 


MSC-BSS 
MSC-BSS 


M 
M 


1 
3-4 



Typical cause values 
Call control 



3.2.1.63 



UPLINK SEIZED COMMAND 



This message is sent from the MSC to the BSS in order to indicate to the BSS that the uplink of the voice group call 
channel is no longer available for allocation. 
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INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Cause 


3.2.2.1 
3.2.2.5 


MSC-BSS 
MSC-BSS 


M 
M 


1 
3-4 



Typical cause values 
Call control 



3.2.1.64 



SUSPEND 



The SUSPEND message is sent from the BSS to the MSC on the SCCP connection associated to an MS transaction. It 
indicates to the receiving entity that the transmitting BSS has detected an overload situation in the corresponding 
connection. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
DLCI 


3.2.2.1 
3.2.2.25 


BSS-MSC 
BSS-MSC 


M 
M 


1 
2 



NOTE: The SUSPEND message may be only useful for PDSS 1 . 



3.2.1.65 



RESUME 



The RESUME message is sent from the BSS to the MSC on the SCCP connection associated to an MS transaction. It 
indicates to the receiving entity that the overload situation in the corresponding connection does no more exist. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
DLCI 


3.2.2.1 
3.2.2.25 


BSS-MSC 
BSS-MSC 


M 
M 


1 
2 



NOTE: The RESUME message may be only useful for PDSS 1 . 

3.2.1.66 CHANGE CIRCUIT 

This message is sent from the MSC to the BSS. It requests a change of the circuit allocated to a connection. 
This message is sent on the relevant SCCP connection. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Cause 


3.2.2.1 
3.2.2.5 


MSC-BSS 
MSC-BSS 


M 
M 


1 
3-4 



Typical Cause values are 

Requested terrestrial ressource unavailable, 
Terrestrial circuit already allocated. 



3.2.1.67 



CHANGE CIRCUIT ACKNOWLEDGE 



This message is sent from the BSS to the MSC.It allocates a new circuit. 
This message is sent on the relevant SCCP connection. 



INFORMATION ELEMENT 


REFERENCE 


DIRECTION 


TYPE 


LEN 


Message Type 
Circuit identity 


3.2.2.1 
3.2.2.2 


BSS-MSC 
BSS-MSC 


M 
M 


1 
3 
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3.2.1.68 Spare 

3.2.2 Signalling element coding 

This paragraph contains the CODING of the signalHng elements used. 

The following conventions are assumed for the sequence of transmission of bits and bytes: 

Each bit position is marked as 1 to 8. Bit 1 is the least significant bit and is transmitted first. 

In an element octets are identified by number, octet 1 is transmitted first, then octet 2 etc. 

When a field extends over more than one octet, the order of bit values progressively decreases as the octet number 
increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet of 
the field. 

For variable length elements a length indicator is included, this indicates the number of octets following in the 
element. 

All fields within Information Elements are mandatory unless otherwise specified. The Information Element 
Identifier shall always be included. 

All spare bits are set to 0. 

The elements used and their CODING are: 



Element 
Identifier 
Coding 


Element name 


Reference 


0000 0001 


Circuit Identity Code 


3.2.2.2 


0000 0010 


Reserved 


* 


0000 0011 


Resource Available 


3.2.2.4 


0000 0100 


Cause 


3.2.2.5 


0000 0101 


Cell Identifier 


3.2.2.17 


0000 0110 


Priority 


3.2.2.18 


0000 0111 


Layer 3 Header Information 


3.2.2.9 


0000 1000 


IMSI 


3.2.2.6 


0000 1001 


TMSI 


3.2.2.7 


0000 1010 


Encryption Information 


3.2.2.10 


0000 1011 


Channel Type 


3.2.2.11 


0000 1100 


Periodicity 


3.2.2.12 


0000 1101 


Extended Resource Indicator 


3.2.2.13 


0000 1110 


Number Of IVlSs 


3.2.2.8 


0000 1111 


Reserved 


* 


0001 0000 


Reserved 




0001 0001 


Reserved 


* 


0001 0010 


Classmark Information Type 2 


3.2.2.19 


0001 0011 


Classmark Information Type 3 


3.2.2.20 


0001 0100 


Interference Band To Be Used 


3.2.2.21 


0001 0101 


RR Cause 


3.2.2.22 


0001 0110 


Reserved 




0001 0111 


Layer 3 Information 


3.2.2.24 


0001 1000 


DLCI 


3.2.2.25 


0001 1001 


Downlink DTX Flag 


3.2.2.26 


0001 1010 


Cell Identifier List 


3.2.2.27 


0001 1011 


Response Request 


3.2.2.28 


0001 1100 


Resource Indication IVIethod 


3.2.2.29 


0001 1101 


Classmark Information Type 1 


3.2.2.30 


0001 1110 


Circuit Identity Code List 


3.2.2.31 


0001 1111 


Diagnostic 


3.2.2.32 




(continued) 
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(concluded) 



Element 
Identifier 
Coding 


Element name 


Reference 


0010 0000 


Layer 3 Message Contents 


3.2.2.35 


0010 0001 


Chosen Channel 


3.2.2.33 


0010 0010 


Total Resource Accessible 


3.2.2.14 


0010 0011 


Cipher Response Mode 


3.2.2.34 


0010 0100 


Channel Needed 


3.2.2.36 


0010 0101 


Trace Type 


3.2.2.37 


00100110 


Triggerid 


3.2.2.38 


00100111 


Trace Reference 


3.2.2.39 


0010 1000 


Transactionid 


3.2.2.40 


0010 1001 


Mobile Identity 


3.2.2.41 


0010 1010 


OMCId 


3.2.2.42 


0010 1011 


Forward Indicator 


3.2.2.43 


0010 1100 


Chosen Encryption Algorithm 


3.2.2.44 


0010 1101 


Circuit Pool 


3.2.2.45 


00101110 


Circuit Pool List 


3.2.2.46 


00101111 


Time Indication 


3.2.2.47 


0011 0000 


Resource Situation 


3.2.2.48 


0011 0001 


Current Channel type 1 


3.2.2.49 


0011 0010 


Queueing Indicator 


3.2.2.50 


0100 0000 


Speech Version 


3.2.2.51 


0011 0011 


Assignment Requirement 


3.2.2.52 




0011 0101 


Talker Flag 


3.2.2.54 


0011 0110 


Connection Release Requested 


3.2.2.3 


0011 0111 


Group Call Reference 


3.2.2.56 


0011 1000 


eMLPP Priority 


3.2.2.56 


0011 1001 


Configuration Evolution Indication 


3.2.2.57 



3.2.2.1 



Information Element codes marked as "reserved" are reserved for use by previous versions of this interface 
specification 

Message Type 



Message Type uniquely identifies the message being sent. It is a single octet element, mandatory in all messages. 
Bit 8 is reserved for future extension of the code set. All unassigned codes are spare. 
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87654321 


00000000 


Reserved. 


ASSIGNMENT MESSAGES 




00000001 


ASSIGNMENT REQUEST 


000000 10 


ASSIGNMENT COMPLETE 


0000001 1 


ASSIGNMENT FAILURE 


HANDOVER MESSAGES 




000 10000 


HANDOVER REQUEST 


00010001 


HANDOVER REQUIRED 


00010010 


HANDOVER REQUEST ACKNOWLEDGE 


00010011 


HANDOVER COMMAND 


00010100 


HANDOVER COMPLETE 


00010101 


HANDOVER SUCCEEDED 


00010110 


HANDOVER FAILURE 


00010111 


HANDOVER PERFORMED 


00011000 


HANDOVER CANDIDATE ENQUIRE 


00011001 


HANDOVER CANDIDATE RESPONSE 


00011010 


HANDOVER REQUIRED REJECT 


000110 11 


HANDOVER DETECT 


RELEASE MESSAGES 




00100000 


CLEAR COMMAND 


00100001 


CLEAR COMPLETE 


00100010 


CLEAR REQUEST 


0010001 1 


RESERVED 


00100100 


RESERVED 


0010010 1 


SAP! "N" REJECT 


00100110 


CONFUSION 


OTHER CONNECTION RELATED MESSAGES 




00101000 


SUSPEND 


00101001 


RESUME 


GENERAL MESSAGES 




00110000 


RESET 


00110001 


RESET ACKNOWLEDGE 


00110010 


OVERLOAD 


00110011 


RESERVED 


00110100 


RESET CIRCUIT 


00110101 


RESET CIRCUIT ACKNOWLEDGE 


00110110 


MSC INVOKE TRACE 


00110111 


BSS INVOKE TRACE 


TERRESTRIAL RESOURCE MESSAGES 




01000000 


BLOCK 


01000001 


BLOCKING ACKNOWLEDGE 


010000 10 


UNBLOCK 


01000011 


UNBLOCKING ACKNOWLEDGE 


01 0001 00 


CIRCUIT GROUP BLOCK 


01000101 


CIRCUIT GROUP BLOCKING ACKNOWLEDGE 


01 0001 1 


CIRCUIT GROUP UNBLOCK 


01000111 


CIRCUIT GROUP UNBLOCKING 




ACKNOWLEDGE 


01001000 


UNEQUIPPED CIRCUIT 


01001110 


CHANGE CIRCUIT 


1001111 


CHANGE CIRCUIT ACKNOWLEDGE 




(continued) 
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(concluded) 



87654321 



RADIO RESOURCE MESSAGES 

01010000 
01010001 
01010010 
01010011 
01010100 
01010101 
01010110 
01010111 
010 11000 
01011001 
01011010 



VGCS/VBS 



00000100 
0000010 1 
000001 1 
00000111 
00011100 
00011101 
00011110 
00011111 
00100111 
01001001 
01001010 
01001011 
01001100 
01001101 



RESOURCE REQUEST 

RESOURCE INDICATION 

PAGING 

CIPHER MODE COMMAND 

CLASSMARK UPDATE 

CIPHER MODE COMPLETE 

QUEUING INDICATION 

COMPLETE LAYER 3 INFORMATION 

CLASSMARK REQUEST 

CIPHER MODE REJECT 

LOAD INDICATION 

VGCS/VBS SETUP 
VGCS/VBS SETUP ACK 
VGCS/VBS SETUP REFUSE 
VGCS/VBS ASSIGNMENT REQUEST 
VGCS/VBS ASSIGNMENT RESULT 
VGCS/VBS ASSIGNMENT FAILURE 
VGCS/VBS QUEUING INDICATION 
UPLINK REQUEST 
UPLINK REQUEST ACKNOWLEDGE 
UPLINK REQUEST CONFIRMATION 
UPLINK RELEASE INDICATION 
UPLINK REJECT COMMAND 
UPLINK RELEASE COMMAND 
UPLINK SEIZED COMMAND 



3.2.2.2 Circuit Identity Code 

This element defines the terrestrial channel over which the call will pass. 

If a 2048Kbits/s digital path is used then the circuit identification code contains in the 5 least significant bits a binary 
representation of the actual number of the timeslot which is assigned to the circuit. The remaining bits in the CIC are used 
where necessary, to identify one among several systems interconnecting an originating and destination point. 

The element is 2 octets in length: 



8 


7 


6 


5 

1 1 


4 


3 


2 


1 




Element identifier 


octet 1 


a 


b 


c 


d 


e 


f 


g 


h 


octet 2 


i 


J 


k 


X 


X 


X 


X 


X 


octet 3 



a-k defines the PCM multiplex in use. 

XXXXX define the actual timeslot in use. 

The circuit identity code defines the PCM multiplex and timeslot in use at the MSC. In cases where remultiplexing takes 
place between the MSC and BSS a translation may be necessary at the BSS. 

3.2.2.3 Connection Release Requested 

The element has a fixed length of one octet 



8 


7 


6 


5 


4 


3 


2 


1 
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Element identifier 



octet 1 



3.2.2.4 



Resource Available 



This element gives the number of full and half rate channels available on any given cell at the time of construction of the 

message. 

It defines these parameters in terms of the number of channels available in five interference bands, the boundaries of these 
bands being set by O and M as follows: 

Interference level; 

Band 1 

XI 

Band 2 

X2 

Band 3 

X3 

Band 4 

X4 

Bands 

X5 

The element is coded as follows: 



8 


7 6 5 4 3 2 1 




Element identifier 


octet 1 


Number of full rate 
channels available in band 1 


octet 2 
octet 3 


Number of half rate 
channels available in band 1 


octet 4 
octet 5 






Number of full rate 
channels available in band 5 


octet 1 8 
octet 1 9 


Number of half rate 
channels available in band 5 


octet 20 
octet 21 



Octets (2,3,4,5,) are then repeated for each of the other interference bands giving a total message length of 21 octets. 

Octets 2 and 3 give a 16 bit binary representation of the number of full rate channels available for service but not 
currently assigned. 

Octets 4 and 5 give a 16 bit binary representation of the number of half rate channels available for service but not 
currently assigned. This will include half rate channels already counted in octets 2 and 3, if these correspond to full rate 
channels that can be used as half rate channels. 

(e.g. If there is a spare half rate channel and a spare full rate channel that can be used as two half rate channels, then the 
full rate count will be 1 and the half rate count will be 3). 

Octets 3 and 5 are the least significant octets, and bit 1 is the least significant bit. 
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3.2.2.5 Cause 

The cause element is used to indicate the reason for a particular event to have occurred and is coded as shown below. 

The cause value is a single octet element if the extension bit (bit 8) is set to 0. If it is set to 1 then the cause value is a 2 
octet field. If the value of the first octet of the cause field is IXXX 0000 then the second octet is reserved for national 
applications, (XXX will still indicate the class). 



8 


7 


6 5 


4 


3 


2 1 




Element identifier 


octet 1 


Length 


octet 2 
octet 3 


0/1 ext 


Cause Value 




(octet 4) 



The length indicator is a binary representation of the length of the following element. 

Cause Value: 

Class (000) : Normal event 

Class (001) : Normal event 

Class (010) : Resource unavailable 

Class (01 1) : Service or option not available 

Class (100) : Service or option not implemented 

Class (101) : invalid message (eg parameter out of range) 

Class (110) : protocol error 

Class (111) : interworking 

In the following table, "reserved for international use" means that this codepoint should not be used until a meaning has 
been assigned to it following the process of international standardisation. "Reserved for national use" indicates 
codepoints that may be used by operators without the need for international standardisation. 
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Cause 


value 




Cause 
Number 




Class 


Value 


7 6 5 


4 3 


2 


1 






















Radio interface message failure 













1 




Radio interface failure 










1 







Uplink quality 










1 


1 




Uplink strength 







1 










Downlink quality 







1 





1 




Downlink strength 







1 


1 







Distance 







1 


1 


1 




and M intervention 







1 










Response to MSC invocation 







1 





1 




Call control 








1 
1 


1 
1 




1 




Radio interface failure, reversion 
old channel 
Handover successful 


to 





1 1 










Better Cell 







1 1 





1 




Directed Retry 







1 1 


1 







Joined group call channel 







1 1 


1 


1 




Traffic 




1 
tc 
1 



1 




1 




1 




} 

[Reserved for international use 
} 




1 
tc 
1 


1 

1 1 




1 




1 




} 

[Reserved for national use 
} 




10 













Equipment failure 




10 








1 




No radio resource available 




10 
10 






1 
1 




1 




Requested terrestrial resource 

unavailable 
CCCH overload 




10 


1 










Processor overload 




10 


1 





1 




BSS not equipped 
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Cause value 


Cause 
Number 




Class 


Value 


10 


1 


1 







MS not equipped 


10 


1 


1 


1 




Invalid cell 


10 


1 










Traffic Load 


10 


1 





1 




Preemption 


10 
tc 
10 


1 

1 1 


1 
1 




1 




} 

}Reserved for national use 
} 


Oil 













Requested transcoding/rate adaption 
unavailable 


Oil 








1 




Circuit pool mismatch 


Oil 





1 







Switch circuit pool 


Oil 





1 


1 




Requested speech version unavailable 


Oil 
tc 
Oil 


1 

1 1 




1 




1 




} 

}Reserved for international use 

} 


10 













Ciphering algorithm not supported 


10 
tc 
10 



1 




1 


1 
1 




} 

}Reserved for international use 

} 


10 
tc 
10 


1 

1 1 


1 
1 


1 
1 




} 

}Reserved for national use 

} 


10 1 













Terrestrial circuit already allocated 


10 1 








1 




Invalid message contents 


10 1 





1 







Information element or field missing 


10 1 





1 


1 




Incorrect value 


10 1 


1 










Unknown Message type 


10 1 


1 





1 




Unknown Information Element 


10 1 
tc 
10 1 


1 
1 


1 
1 




1 




} 

}Reserved for international use 

} 


10 1 
tc 
10 1 


1 

1 1 




1 




1 




} 

}Reserved for national use 

} 
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Cause value 



Class 



Value 



Cause 
Number 



110 

110 

110 

to 
110 




1 
10 
111 
10 



110 

to 
110 1111 



Protocol Error between BSS and MSC 
VGCS/VBS call non existent 

Reserved for international use 
Reserved for national use 



1110 
to 



111 



111 
10 



111 

to 
1 1 111 1 1 1 



Reserved for international use 



Reserved for national use 



3.2.2.6 



IMSI 



The IMSI is coded as a sequence of BCD digits, compressed two into each octet. This is a variable length element, and 
includes a length indicator. The remainder of this element is coded as defined in GSM 04.08. 

The element coding is: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Length 


octet 2 


Rest of element coded as in GSM 04.08, 

not including GSM 04.08 element identifier 

or GSM 04.08 octet length value 


octet 3 - n 



3.2.2.7 TMSI 

The TMSI is a fixed length element. The TMSI is an unstructured number of 4 octets in length. 
The coding is: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Length 


octet 2 


TMSI 


octet 3-6 



The TMSI field is unstructured. 

3.2.2.8 Number Of MSs 

This is a fixed length element which indicates the number of handover candidates that have been sent to the MSC. 
The coding is: 
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8 


7 ' 6 ' 5 ' 4 ' 3 ' 2 
1 1 1 1 1 


1 




Element identifier 


octet 1 


Number of handover candidates 


octet 2 



Octet 2 is a binary indication of the number of handover candidates. Bit 1 is the least significant bit. 



3.2.2.9 



Layer 3 Header Information 



This element is used to supply the BSS with information that needs to be included in the header of layer 3 messages over 
the radio interface. 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Length 


octet 2 


Protocol discriminator 


octet 3 


Transaction identifier 


octet 4 



The length indicator is a binary indication of the number of octets following in the element. 

The transaction identifier and protocol discriminator fields are coded as defined in GSM 04.08. The protocol 
discriminator occupies bit 1 to 4 in octet 3 of Layer 3 header information, the Transaction identifier occupies bit 1 to 4 in 
octet 4 of the Layer 3 header information. 

3.2.2.10 Encryption Information 

This element contains the user data encryption information used to control any encryption equipment at the BSS. 
It is a variable length element. 
It is coded as follows: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Length 


octet 2 


Permitted algorithms 


octet 3 


Key 


octet 4 - n 



The length indicator (octet 2) is a binary number indicating the absolute length of the contents after the length indicator 
octet. 

The permitted algorithms octet is a bit map indicating the A5 encryption algorithms and no encryption. From this bit map 
the BSS may select an A5 algorithm or no encryption to be used. 

Bit No 

1 No encryption 

2 GSMA5/1 

3 GSMA5/2 

4 GSMA5/3 

5 GSMA5/4 

6 GSMA5/5 

7 GSMA5/6 

8 GSMA5/7 
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A bit position encoded as 1 indicates that the BSS may use the option repesented by that bit position. A bit position 
encoded as indicates that the BSS shall not use the option represented by that bit position. A permitted algorithms octet 
containing all bits encoded as shall not be used. 

The key shall be present if at least one of the A5 encryption algorithms is permitted. When present, the key shall be 8 
octets long. 

3.2.2.11 Channel Type 

This element contains all of the information that the BSS requires to determine the required radio resource(s). 

The channel type information element has a mirumum length of 5 octets and a maximum length of 10 octets. It is coded as 
follows: 



8 


' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Length 


octet 2 


Spare 


Speech / data indicator 


octet 3 


Channel rate and type 


octet 4 


Permitted speech version indication / 
data rate + transparency indicator 


octet 5 
or 
octet 5 with 
extension * 



If the speech / data indicator (octet 3) indicates "speech" or "data", octet 5 may optionally be extended. 
Otherwise octet 5 shall not be extended. 



The "speech / data indicator" field is coded as follows: 
0001 Speech 

0010 Data 

0011 Signalling 
All other values are reserved. 

For values 0001 and 0010 a dedicated terrestrial resource is also required. 
The "channel rate and type" is coded as follows: 
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If octet 3 indicates data then octet 4 shall be coded as: 

0000 1 000 Full rate TCH channel Bm 

0000 1 00 1 Half rate TCH channel Lm 

0000 1010 Full or Half rate TCH channel, Full rate preferred, changes allowed also after first channel 

allocation as a result of the request. 

0000 1011 Full or Half rate TCH channel. Half rate preferred, changes allowed also after first channel 

allocation as a result of the request. 

0001 1010 Full or Half rate TCH channel. Full rate preferred, changes not allowed after first channel allocation 

as a result of the request. 

0001 1011 Full or Half rate TCH channel. Half rate preferred, changes not allowed after first channel 

allocation as a result of the request. 

0010 Oxxx Full rate TCH channels in a multislot configuration, changes by the BSS of the the number of TCHs 

and if applicable the used radio interface rate per channel allowed after first channel allocation as a 
result of the request. 

001 1 Oxxx Full rate TCH channels in a multislot configuration, changes by the BSS of the number of TCHs or 

the used radio interface rate per channel not allowed after first channel allocation as a result of the 
request. 

XXX (bits 3-1) indicates maximum number of traffic channels; 



321 




000 


ITCHs 


001 


2 TCHs 


010 


3 TCHs 


Oil 


4 TCHs 


100 


5 TCHs 


101 


6 TCHs 


110 


7 TCHs 


111 


8 TCHs 



All other values are reserved. 

If octet 3 indicates speech then octet 4 shall be coded as: 

0000 1000 Full rate TCH channel Bm. Preference between the permitted speech versions for full rate TCH as 

indicated in octet 5, 5a etc.. 

0000 1001 Half rate TCH channel Lm. Preference between the permitted speech versions for half rate TCH as 

indicated in octet 5, 5a etc.. 

0000 1010 Full or Half rate TCH channel. Full rate preferred, changes between full rate and half rate allowed 

also after first channel allocation as a result of the request. Preference between the permitted speech 
versions for the respective channel rates as indicated in octet 5, 5a etc. 

0000 1011 Full or Half rate TCH channel. Half rate preferred, changes between full rate and half rate allowed 

also after first channel allocation as a result of the request. Preference between the permitted speech 
versions for the respective channel rates as indicated in octet 5, 5a etc. 

0001 1010 Full or Half rate TCH channel. Full rate preferred, changes between full rate and half rate not 

allowed after first channel allocation as a result of the request. Preference between the permitted 
speech versions for the respective channel rates as indicated in octet 5, 5a etc. 

0001 1011 Full or Half rate TCH channel. Half rate preferred, changes between full rate and half rate not 

allowed after first channel allocation as a result of the request. Preference between the permitted 
speech versions for the respective channel rates as indicated in octet 5, 5a etc. 

0000 1111 Full or Half rate TCH channel. Preference between the permitted speech versions as indicated in 

octet 5, 5a etc., changes between full and half rate allowed also after first channel allocation as a 
result of the request 
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0001 1111 Full or Half rate TCH channel. Preference between the permitted speech versions as indicated in 

octet 5, 5a etc., changes between full and half rate not allowed after first channel allocation as a 
result of the request 

All other values are reserved. 

If octet 3 indicates signalling then octet 4 shall be coded as: 

0000 0000 SDCCH or Full rate TCH channel Bm or Half rate TCH channel Lm 

0000 0001 SDCCH 
0000 00 1 SDCCH or Full rate TCH channel Bm 

0000 00 1 1 SDCCH or Half rate TCH channel Lm 

0000 1 000 Full rate TCH channel Bm 

0000 1 00 1 Half rate TCH channel Lm 

0000 1010 Full or Half rate TCH channel, Full rate preferred, changes allowed also after first channel 

allocation as a result of the request. 

0000 1011 Full or Half rate TCH channel. Half rate preferred, changes allowed also after first channel 

allocation as a result of the request. 

0001 1010 Full or Half rate TCH channel. Full rate preferred, changes not allowed after first channel allocation 

as a result of the request. 
0001 1011 Full or Half rate TCH channel. Half rate preferred, changes not allowed after first channel 

allocation as a result of the request. 
All other values are reserved. 

The " permitted speech version indication / data rate + transparency indicator" octet is coded as follows: 
If octet 3 indicates speech then octet 5 shall be coded as follows: 



8 


7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 




ext 


permitted speech version identifier 


octet 5 


ext 


permitted speech version identifier 


octet 5a 


ext 


permitted speech version identifier 


octet 5b 


ext 


permitted speech version identifier 


octet 5c 


ext 


permitted speech version identifier 


octet 5d 





permitted speech version identifier 


octet 5e 



Bit 8 indicates extension of octet 5. 

no extension, i.e. value "0" indicates that this octet is the last octet. 

1 extension, i.e. value "1" indicates that at least one additional octet is included. 

If more than one permitted speech version is indicated by octet 5 (with extension), then the speech version choice is left to 
the BSS. 
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Bits 7-1 indicate the permitted speech version identifier; 



765 4321 

000 0001 

001 0001 
010 0001 

000 0101 

001 0101 
010 0101 



GSM speech full rate version 1 
GSM speech full rate version 2 
GSM speech full rate version 3 
GSM speech half rate version 1 
GSM speech half rate version 2 
GSM speech half rate version 3 



NOTE: Bits 7-1 indicate six speech versions. 

All other values of permitted speech version identifiers are for future use. If an unknown value is received and 
more than one octet 5 is received the sender expects the receiver to behave as if it has made a choice of 
speech version. 

The rules for coding preferences in octet 5, 5a - 5e are the following: 

In those cases when one specific channel rate is indicated in octet 4, the non-empty set of permitted speech 
versions is included. Within this set the permitted speech versions are included in order of speech version 
preferences. 

In those cases when a preference for a channel rate is indicated in octet 4, the non-empty sets of permitted speech 
versions for the respective channel rate are included in order of the channel rate preferences indicated in octet 4. 
Within a set of permitted speech versions for a channel rate, the permitted speech versions are included in order of 
speech version preferences. 

In those cases when no preference or specific channel rate is indicated in octet 4, the permitted speech versions 
are included in order of speech version preferences. 

Always octet 5 has the highest preference followed by octet 5a and so on. For each channel rate allowed by octet 4 at 
least one speech version shall be present. 

If octet 5 indicates no extension and bits 7-1 is coded "000 0001", then the preference is interpreted based upon the octet 
4 value as follows: 

- in those cases when octet 4 indicates one specific channel rate, then "speech version 1" for the indicated channel 
rate is permitted. 

- in those cases when octet 4 indicates a preference for a channel rate, then "speech version 1" for any of the 
allowed channel rates is permitted. 

in those cases when octet 4 does neither indicate a preference for a channel rate nor a specific channel rate, then 
"speech version 1" for any of the allowed channel rates is permitted and speech full rate version 1 is preferred. 

If octet 3 indicates data, and octet 4 does not indicate multislot configuration, then octet 5 shall be coded as follows: 



8 


7 


6 ' 

1 


5 ' 4 


' 3 ' 2 ' 
1 1 1 


1 




ext 


T/NT 


Rat 
1 


:e 

1 1 1 


octet 5 


ext 


spare 


allowed 

r i/f rates 


octet 5a 



Bit 8 indicates extension of octet 5. 

no extension, i.e. value "0" indicates that this octet is the last octet. 

1 extension, i.e. value "1" indicates that at least one additional octet is included. 
Bit 7: 

Transparent service 

1 Non-transparent service. 



For non-transparent service bits 6-1 indicate the radio interface data rate; 

65 4321 

00 0000 1 2 kbit/s if the channel is a full rate TCH, or 
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6 kbit/s if the channel is a half rate TCH 
01 1000 14.5 kbit/s 

010000 12kbits/s 

010001 6kbits/s 

If bit 7 in octet 5 indicates non-transparent service and octet 5a is included the 'rate' in octet 5 indicates the wanted air 
interface data rate and the 'allowed r i/f rates' indicates the other possible data rates allowed. 

All other values are reserved. 

For transparent service bits 6-1 indicate the data rate; 



65 4321 




01 1000 


14.4 kbit/s 


01 0000 


9.6kbit/s 


01 0001 


4.8kbit/s 


01 0010 


2.4kbit/s 


010011 


1.2Kbit/s 


01 0100 


600 bit/s 


010101 


1200/75 bit/s (1200 network-to-MS / 75 MS-to-network) 



If bit 7 in octet 5 indicates transparent service octet 5 shall not be extended. 
All other values are reserved. 
Octet 5a shall be coded as follows; 



Bits 



reserved for extension. 

A coding of indicates no extension 



Bits 4 to 1 indicate allowed radio interface data rate, per channel; 



Bit 4: 

Bit 3: 
Bit 2: 

Bit 1: 



14.5 kbit/s (TCH/F14.4) not allowed 

1 14.5 kbit/s (TCH/F14.4) allowed 

Spare 

12.0 kbit/s (TCH/F9.6) not allowed 

1 12.0 kbit/s (TCH/F9.6) allowed 

6.0 kbit/s (TCH/F4.8) not allowed 

1 6.0 kbit/s (TCH/F4.8) allowed 



If octet 3 indicates data and octet 4 indicates Full rate TCH channels in a multislot configuration, octet 5 and 5 a shall be 
coded as follows; 



8 


7 


6 ' 

1 


5 ' 4 
1 


3 


2 ' 1 
1 




ext 


T/NT 


Rate 


octet 5 


ext 


spare 




allowed 

r i/f rate 


octet 5a 



Octet 5 shall be coded as follows; 



Bit 8: 



Bit 7: 



extension bit 

indicates no extension 

1 indicates that at least one additional octet is included 

Transparent service 

1 Non-transparent service. 
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For non-transparent service bits 6-1 indicates wanted total radio interface data rate; 

65 4321 

01 01 10 58 kbit/s (4x14.5 kbit/s) 

01 0100 48.0 / 43.5 kbit/s (4x12 kbit/s or 3x14.5 kbit/s) 

01 001 1 36.0 / 29.0 kbit/s (3x12 kbit/s or 2x14.5 kbit/s) 

01 0010 24.0 / 24.0 / 29.0 kbit/s (4x6 kbit/s or 2x12 kbit/s or 2x14.5 kbit/s) 

01 0001 18.0 / 24.0 / 14.5 kbit/s (3x6 kbit/s or 2x12 kbit/s or 1x14.5 kbit/s) 

01 0000 12.0 / 14.5 kbit/s (1x12 kbit/s or 1x14.5 kbit/s) 

All other values are reserved. 

For transparent service bits 6-1 indicates requested air interface user rate; 



65 4321 




01 nil 


64 kbit/s, bit transparent 


01 1110 


56 kbit/s, bit transparent 


01 1101 


56 kbit/s 


01 1100 


48 kbit/s 


01 1011 


38.4 kbit/s 


01 1010 


28.8 kbit/s 


01 1001 


19.2 kbit/s 


01 1000 


14.4 kbit/s 


01 0000 


9.6 kbit/s 



All other values are reserved. 
Octet 5a shall be coded as follows; 

Bit 8 reserved for extension. 

A coding of indicates no extension 

Bits 4 to 1 indicates allowed radio interface data rate, per channel; 

Bit 4: 14.5/14.4 kbit/s (TCH/F14.4) not allowed 

1 14.5/14.4 kbit/s (TCH/F14.4) allowed 

Bit 3: Spare 

Bit 2: 12.0/9.6 kbit/s (TCHF/9.6) not allowed 

1 12.0/9.6 kbit/s (TCH F/9.6) allowed 

Bitl: 6.0/4.8 kbit/s (TCH F/4.8) not allowed 

1 6.0/4.8 kbit/s (TCH F/4.8) allowed 

If octet 5a is not included, allowance of radio interface data rates of 12.0 and 6.0 shall be presumed. 

NOTE: For data services, the information in the channel type Information Element is used to set the "E-bits" and 
map the "D-bits" (as described in GSM 04.21 and 08.20) and to select the correct channel coding. 

If octet 3 indicates signalling then octet 5 is spare. 

3.2.2.12 Periodicity 

This element defines the periodicity of a particular procedure. It is fixed length, 2 octets. 
The coding is as follows: 
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8 


7 


6 ' 5 ' 4 ' 3 
1 1 1 


2 


1 




Element identifier 


octet 1 


Periodicity 


octet 2 



When the Resource Indication Method IE is set to either "method i) of subclause 3.1.3.1" or "method iii) of subclause 
3.1.3.1" and the periodicity parameter is not 0000 0000 then the coding of the periodicity parameter is; 



0000 0001 
nil 1111 



Period 



where the period is the binary value of octet 2 * 100 ms (ie 100 ms to 25,500 ms). 

When the Resource Indication Method IE is set to "method i) of subclause 3.1.3.1" and the periodicity parameter is 0000 
0000 then the BSS shall ignore this IE. 

When the Resource Indication Method IE is set to "method iii) of subclause 3.1.3.1" and the periodicity parameter is 0000 
0000 then the BSS shall treat the message according to subclause 3.1.19.4, case 2. 

When the Resource Indication Method IE is set to either "method ii) of subclause 3.1.3.1" or "method iv) of subclause 
3.1.3.1" then the Periodicity IE shall be ignored. 



3.2.2.13 



Extended Resource Indicator 



This element defines which additional resource information related to a given cell the BSS shall transfer to the MSC. It 
may also indicate the subsequent reporting mode for that cell. 

The coding is as follows: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


spare 


SM 


TARR 


octet 2 



SM = Subsequent mode 

TARR = Total Accessible Resource Requested 

The coding of the Total Accessible Resource Requested field is as follows: 

no extra Resource Information is requested 

1 The total number of accessible channels is requested 

If the Resource Indication Method is not set to "method ii of subclause 3.1.3.1" then the Subsequent Mode field is ignored. 

If the Resource Indication Method is set to "method ii of subclause 3.1.3.1" then the Subsequent Mode field is decoded as 
follows: 

method iv) of subclause 3.1.3.1. 

1 if the reporting mode prior to receipt of this IE was i) or iii) of subclause 3.1.3.1 then the subsequent mode shall 
be respectively i) or iii); otherwise the subsequent mode shall be method iv) of subclause 3.1.3.1. 



3.2.2.14 



Total Resource Accessible 



This element gives the total number of full and half rate channels accessible on any given cell at the time of construction of 
the message. 

It defines these parameters in terms of the number of channels which are accessible or in use. No separation between the 
defined interference bands is made. 

The element is coded as follows: 
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8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Total number of accessible 
full rate channels 


octet 2 
octet 3 


Total number of accessible 
half rate channels 


octet 4 
octet 5 



Octets 2 and 3 give a 16 bit binary representation of the total number of full rate channels accessible (i.e. available for 
service or currently assigned). 

Octets 4 and 5 give a 16 bit binary representation of the number of half rate channels accessible (i.e. available for service 
or currently assigned). This will include half rate channels already counted in octets 2 and 3, if these correspond to full 
rate channels that can be used as half rate channels. 

(eg. If there is an accessible half rate channel and an accessible full rate channel that can be used as two half rate 
channels, then the full rate count will be 1 and the half rate count will be 3). 

Octets 3 and 5 are the least significant octets, and bit 1 is the least significant bit. 

3.2.2.15 [spare] 

3.2.2.16 [spare] 

3.2.2.17 Cell Identifier 

This element uniquely identifies a cell within a BSS and is of variable length containing the following fields: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Length 


octet 2 


Spare 


Cell identification 
discriminator 


octet 3 


Cell identification 


octet 4 - n 



The coding of octet 2 is a binary number indicating the length of the remaining element. The length depends on the Cell 
identification discriminator (octet 3). 

The coding of "Cell identification discriminator" (bits 1 to 4 of octet 3) is a binary number indicating if the whole or a 
part of Cell Global Identification, CGI, according to GSM 03.03 is used for cell identification in octet 4-n. The "Cell 
identification discriminator" is coded as follows: 



0000 
0001 
0010 
0011 



The whole Cell Global Identification, CGI, is used to identify the cell. 
Location Area Code, LAC, and Cell Identity, CI, is used to identify the cell. 
Cell Identity, CI, is used to identify the cell. 
No cell is associated with the transaction. 



All other values are reserved. 

The coding of octet 4-n depends on the Cell identification discriminator (octet 3). Below the coding is shown for each 
Cell identification discriminator: 

Note that no coding is specified for a Cell identification discriminator value of "00 11" as no additional information is 
required. 

Coding of Cell Identification for 

Cell identification discriminator = 0000 
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8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




MCC dig 2 


MCC dig 1 


octet 4 


1111 


MCC dig 3 


octet 5 


MNC dig 2 


MNC dig 1 


octet 6 


LAC 


octet 7 


LAC cont. 


octet 8 


CI value 


octet 9 


CI value cont 


octet 10 



The octets 4-8 are coded as shown in GSM 04.08, Table 'Location Area Identification information element' 

The octets 9-10 are coded as shown in GSM 04.08, Table 'Cell Identity information element' . 

Coding of Cell Identification for 

Cell identification discriminator = 0001 



8 


7 


6 ' 5 ' 4 ' 
1 1 1 


3 


2 ' 1 

1 




LAC 


octet 4 


LAC cont. 


octet 5 


CI value 


octet 6 


CI value cont 


octet 7 



Coding of Cell Identification for 

Cell identification discriminator = 0010 



8 


7 


6 ' 5 

1 


4 ' 

1 


3 


2 


1 




CI value 


octet 4 






CI value 


cont 








octet 5 



The octets 4-5 are coded as shown in GSM 04.08, Table 'Cell Identity information element' 

3.2.2.18 Priority 

This element indicates the priority of the request. It is coded as follows: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Length 


octet 2 


Priority 


octet 3 



Octet 2 is a binary indication of the length of the rest of the element. 
Octet 3 is coded as follows: 



8 ' 7 


6 ' 5 ' 4 ' 3 
1 1 1 


2 


1 




spare 


pel 


priority level 


qa 


pvi 


octet 3 



Bit 8 is spare, set to 
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pci = Preemption Capability indicator (see note) 




1 

priority level: 

6543 
0000 
0001 
0010 

1110 
1111 



this allocation request shall not preempt an existing connection 
this allocation request may preempt an existing connection 



spare 

priority level 1 = highest priority 

priority level 2 = second highest priority 



priority level 14 = lowest priority 
priority not used 



qa = queueing allowed indicator 




1 



queueing not allowed 
queueing allowed 



pvi = Preemption Vulnerability indicator (see note) 




1 



this connection shall not be preempted by another allocation request 
this connection might be preempted by another allocation request 



NOTE: Preemption Capability indicator applies to the allocation of resources for an event and as such it provides 
the trigger to the preemption procedures/processes of the BSS. Preemption Vulnerability indicator applies 
for the entire duration of a connection and as such indicates whether the connection is a target of the 
preemption procedures/processes of the BSS. 

3.2.2.1 9 Classmark Information Type 2 

The classmark information type 2 defines certain attributes of the mobile station equipment in use on a particular 
transaction. 

It is coded as follows: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Length 


octet 2 


Classmark 


octet 3-5 



Octet 2 is a binary indication of the length of the remainder of the element in octets. The length shall be determined by the 
length of the Mobile Station Classmark 2 element of GSM 04.08. 

The classmark octets 3, 4 and 5 are coded in the same way as the equivalent octets in the Mobile station classmark 2 
element of GSM 04.08. 

3.2.2.20 Classmark Information Type 3 

The classmark information type 3 defines certain attributes of the mobile station equipment in use on a particular 
transaction. 

It is coded as follows: 
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8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Length 


octet 2 


Classmark 


octet 3-14 



Octet 2 is a binary indication of the length of the remainder of the element in octets. The length octet has a minimum value 
of 1 and a maximum of 12. The length shall be determined by the length of the Mobile Station Classmark 3 element of 
GSM 04.08. 

The classmark octets 3 to 14 are coded in the same way as the equivalent octets in the Mobile station classmark 3 element 
of GSM 04.08. 

3.2.2.21 Interference Band To Be Used 

This fixed length element is coded as follows: 



8 


7 


6 ' 5 ' 4 ' 3 
1 1 1 


2 


1 




Element identifier 


octet 1 


Band to be used 


octet 2 



Octet 2 is coded as: 

Bits 876 
Bits 54321 



Spare 

A bit map indicating which interference bands are acceptable, the LSB represents the least level of 

interference. 



3.2.2.22 



RR Cause 



This fixed length element is passed from the radio interface to the MSC transparently, when received in a GSM 04.08 

message. 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


RR cause 


octet 2 



Octet 2 is coded as the equivalent field from GSM 04.08. 

3.2.2.23 Spare 

3.2.2.24 Layer 3 Information 

This is a variable length element used to pass radio interface messages from one network entity to another. 



8 


7 


6 ' 5 

1 


' 4 ' 3 ' 
1 1 1 


2 


1 








Element 


identifier 






octet 1 


Length 


octet 2 






Layer 3 


information 






octet 3 - 


- n 



Octet 1 identifies the element. Octet 2 gives the length of the following layer 3 information. 



ETSI 



GSM 08.08 version 6.2.0 Release 1997 



91 



TS 100 590 V6.2.0 (1998-11) 



Octet j (j = 3, 4, ..., n) is the unchanged octet j-2 of a radio interface layer 3 message as defined in GSM 04.08, n-2 is 
equal to the length of that radio interface layer 3 message. 

3.2.2.25 DLCI 

This is a fixed length element indicating the radio interface SAPI. 



8 


7 


6 ' 5 

1 


' 4 ' 3 
1 1 


2 


1 








Element 


identifier 






octet 1 


DLCI 


octet 2 



Octet 2 is coded as the DLCI octet described in 08.06. 

3.2.2.26 Downlink DTX Flag 

A fixed length element indicating whether the DTX function in the BSS is to be disabled on a particular radio channel. 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Downlink DTX flag 


octet 2 



The Downlink DTX Flag is coded as follows; 
bits 8 to 2 are spare; 
bit 1 is set to one if the MSC forbids the BSS to activate DTX in the downlink direction; it is set to otherwise. 



3.2.2.27 Cell Identifier List 

This element uniquely identifies cells and is of variable length containing the following fields: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Length 


octet 2 


Spare 


Cell identification 
discriminator 


octet 3 


Cell identification 1 


octet 4-4+m 






Cell identification n 


. . to 4+nm 



The coding of octet 2 is a binary number indicating the Length of the remaining element. The Length depends on the Cell 
identification discriminator (bits 1 to 4 of octet 3) as well as the number of cells to be identified. 

The coding of the Cell identification discriminator is a binary number indicating if the whole or a part of Cell Global 
identification, CGI, according to GSM 03.03 is used for cell identification of the cells in the list. The Cell identification 
discriminator is coded as follows: 



0000 
0001 
0010 
0011 
0100 
0101 



The whole Cell Global Identification, CGI, is used to identify the cells. 

Location Area Code, LAC, and Cell Identify, CI, is used to identify the cells. 

Cell Identity, CI, is used to identify the cells. 

No cell is associated with the transaction. 

Location Area Identification, LAI, is used to identify all cells within a Location Area. 

Location Area Code, LAC, is used to identify all cells within a location area. 
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0110 All cells on the BSS are identified. 

All other values are reserved. 

Values 0100, 0101 and 01 10 are only applicable for page message. 

The coding of the Cell Identifications 1 to n (octets 4 to 4+nm) depends on the Cell identification discriminator (octet 3). 
Below the coding of the i-th Cell Identification is shown for each Cell identification discriminator (with "i" in the range 1 
ton): 

Note that no coding is specified for Cell identification discriminator values of "0011" and "0110" as no additional 
information is required. 

Coding of the i-th Cell Identification for 
Cell identification discriminator = 0000 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
III III 




MCC dig 2 


MCC dig 1 


octet x+1 


1111 


MCC dig 3 


octet x+2 


MNC dig 2 


MNC dig 1 


octet x+3 


LAC 


octet x+4 


LAC cont. 


octet x+5 


CI value 


octet x+6 


CI value cont 


octet x+7 



Where x = 3 + 7(i-l). 

The octets (x+l)-(x+5) are coded as shown in GSM 04.08, Table 'Location Area Identification information element' 

The octets (x+6)-(x+7) are coded as shown in GSM 04.08, Table 'Cell Identity information element' . 

Coding of i-th Cell Identification for 
Cell identification discriminator = 0001 



8 


7 


6 ' 5 ' 4 ' 
1 1 1 


3 


2 ' 1 
1 




LAC 


octet x+1 


LAC cont. 


octet x+2 


CI value 


octet x+3 


CI value cont 


octet x+4 



Wherex=3H-4(i-l) 

The octets (x-i-l)-(x-i-2) are coded as shown in GSM 04.08, Table 'Location Area Identification information element' 

The octets (x-i-3)-(x-i-4) are coded as shown in GSM 04.08, Table 'Cell Identity information element'. 

Coding of i-th Cell Identification for 
Cell identification discriminator = 0010 



8 


7 


6 ' 5 ' 4 ' 
1 1 1 


3 


2 


1 




CI value 


octet x+1 


CI value cont 


octet x+2 



Wherex=3H-2(i-l) 
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The octets (x+l)-(x+2) are coded as shown in GSM 04.08, Table 'Cell Identity infonnation element' 

Coding of i-th Cell Identification for 
Cell identification discriminator = 0100 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
III III 




MCC dig 2 


MCC dig 1 


octet x+1 


1111 


MCC dig 3 


octet x+2 


MNC dig 2 


MNC dig 1 


octet x+3 


LAC 


octet x+4 


LAC cont. 


octet x+5 



Where x = 3 + 5(i-l) 

The octets (x+l)-(x+5) are coded as shown in GSM 04.08, Table 'Location Area Identification information element' 

Coding of i-th Cell Identification for 
Cell identification discriminator = 0101 



8 


7 


6 ' 5 ' 
1 1 


4 


3 


2 


1 




LAC 


octet x+1 


LAC cont. 


octet x+2 



Where x = 3 + 2(i-l) 

The octets (x+l)-(x+2) are coded as shown in GSM 04.08, Table 'Location Area Identification information element' . 

The appropriate coding for not identified cells is "0" for all bits of LAC and CI for all possible Cell Identification 
Discriminator values. 

3.2.2.28 Response Request 

The presence of this element indicates that a Handover Required Reject message is required by the BSS, if the Handover 
Required message does not result in a handover. 

The element has a fixed length of one octet; 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 



3.2.2.29 



Resource Indication Method 



This element defines the way the BSS shall transfer the resource information related to a cell to the MSC. The coding is as 
follows: 



8 


1 1 

7 
1 1 


6 ' 5 

1 


' 4 ' 3 ' 2 ' 1 
1 1 1 1 








Element 


identifier 


octet 1 




Spare 




Resource indication 
method 
1 


octet 2 



The coding of the Resource Indication parameter is: 



0000 
0001 
0010 



the method i) of subclause 3.1.3.1 is selected, 
the method ii) of subclause 3.1.3.1 is selected, 
the method iii) of subclause 3.1.3.1 is selected. 
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0011 the method iv) of subclause 3.1.3.1 is selected. 

All other values are reserved. 

3.2.2.30 Classmark Information Type 1 

The classmark information type 1 defines certain attributes of the mobile station equipment in use on a particular 
transaction. 

It is coded as follows: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Classmark 


octet 2 



The classmark octet 2 is coded in the same way as the equivalent octet in the classmark 1 element of 04.08. 

3.2.2.31 Circuit Identity Code List 

This element defines in conjunction with a Circuit Identity Code (3.2.2.2.) a list of terrestrial channels. 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Length 


octet 2 


Range 


octet 3 


Status 


octet 4-35 



The following codes are used in the range and status fields: 

Range: 

A number in pure binary representation ranging from to 255. The number represented by the range code +1 
indicates the range of circuits affected by the message. 



Status: 



The Status subfield contains up to 256 Status bits numbered from up to 255. Status bit is located in bit position 
1 of the first Status subfield octet and refers to the circuit indicated in the CIC subfield {should be "associated 
Circuit Identity Code Information Element" not "CIC subfield" } itself. Other Status bits follow in numerical order. 

Each Status bit is associated with a circuit identification code such that Status bit n is associated with CIC m+n, 
where m is the CIC contained in the message. { "where m is the CIC identified in the asociated Circuit Identity Code 
Information Element in the message" } 

Status bit n is located in bit position nb of the no-th octet of the Status subfield with: 

nb = (n mod 8) + 1 

and 

no = (ndiv8) + 1. 



The number of relevant Status bits in a given Status subfield is equal to the range value +1. 
The Status bits are coded as follows: 
- in the CIRCUIT GROUP BLOCK message 
no indication 
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1 block 

- in the CIRCUIT GROUP BLOCKING ACKNOWLEDGE message 

no indication 

1 blocking acknowledgement 

- in the CIRCUIT GROUP UNBLOCK message 

no indication 

1 unblock 

- in the CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE message 

no indication 

1 unblocking acknowledgement 

- in the UNEQUIPPED CIRCUIT message 

no indication 

1 unequipped 

3.2.2.32 Diagnostics 



8 ' 7 ' 6 ' 5 ' 4 ' 3 
1 1 1 1 1 


2 ' 1 

1 




Element identifier 


octet 1 


Length 


octet 2 


Error pointer 


octet 3-4 


Message received 


octet 5-n 



The coding of the error pointer field is as follows: 

Octet 3 gives the number of octets between octet 4 (not included) and the first octet (included) of the part of the message 
received which provoked the error. Thus: 



0000 0000 
0000 0001 
0000 0010 
0000 0011 

etc. 



Error location not determined 

The first octet of the message received (i.e. the message type) was found erroneous (unknown) 

The second octet of the message received was found erroneous 

The third octet of the message received was found erroneous 



The last three values are reserved for the BSSAP header: 

1111 1101 The first octet of the BSSAP header (Discrimination) was found erroneous 

1 1 1 1 1110 (DTAP only) The DLCI (second) octet of the BSSAP header was found erroneous 

1111 1111 The last octet of the BSSAP header (length indicator) was found erroneous 

Octet 4 is coded as follows: 

bit 87654321 









spare 



bit pointer 



The bit pointer field is coded as follows: 

bits 4321 

0000 No particular part of the octet is indicated 
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0001 


An error 


0010 


An error 


0011 


An error 


0100 


An error 


0101 


An error 


Olio 


An error 


0111 


An error 


1000 


An error 



was provoked by the 
was provided by the 
was provided by the 
was provided by the 
was provided by the 
was provided by the 
was provided by the 
was provided by the 



field whose 
field whose 
field whose 
field whose 
field whose 
field whose 
field whose 
field whose 



most SI 
most si| 
most si| 
most sij 
most sij 
most sij 
most si| 
most sis 



gnificant bit is 
;nificant bit is 
;nificant bit is 
;nificant bit is 
;nificant bit is 
jnificant bit is 
;nificant bit is 
mificant bit is 



in bit position 1 
in bit position 2 
in bit position 3 
in bit position 4 
in bit position 5 
in bit position 6 
in bit position 7 
in bit position 8 



All other values are reserved. 

The "message received" field should be the contents, as far as can be determined, of the received message which 
provoked the error. 

3.2.2.33 Chosen Channel 

This Information Element contains a description of the channel allocated to the MS. 

For VGCSA^BS calls this Information Element contains a description of the channel allocated for the call in the cell. 

It is coded as follows: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Channel mode 


Channel 


octet 2 



The channel mode field is coded as follows: 

Bit 8765 

0000 no channel mode indication 
1001 speech (full rate or half rate) 
1110 data, 14.5 kbit/s radio interface rate 
101 1 data, 12.0 kbit/s radio interface rate 

1 100 data, 6.0 kbit/s radio interface rate 

1101 data, 3.6 kbit/s radio interface rate 
1000 signalling only 

All other values are reserved. 

The channel field is coded as follows: 



Bit 



4321 

0000 None (Note*) 

0001 SDCCH 

1000 1 Full rate TCH 

1001 1 Half rate TCH 

1010 2 Full Rate TCHs 

1011 3 Full Rate TCHs 

1100 4 Full Rate TCHs 

1101 5 Full Rate TCHs 
1110 6 Full Rate TCHs 
nil 7 Full Rate TCHs 
0100 8 Full Rate TCHs 
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NOTE *: This value may be returned in the chosen channel information for VGCSA'^BS calls in the case where the 
BSS has decided to de-allocate resources or allocate no resources for the call. 

All other values are reserved. 

3.2.2.34 Cipher Response Mode 

This information element is used by the MSC to indicate whether the IMEI is to be included in the CIPHERING MODE 
COMPLETE message to be sent by the Mobile Station. 



8 


7 


6 ' 5 ' 4 ' 3 ' 
1 1 1 1 


2 


1 




Element identifier 


octet 1 


Cipher response mode 


octet 2 



Octet 2 is coded as:- 

Bits 8,7,6,5,4,3,2 - Spare 

Bit 1 = - IMEISV must not be included by the Mobile Station 
Bit 1 = 1 - IMEISV must be included by the Mobile Station 

3.2.2.35 Layer 3 Message Contents 

This is a variable length element used to pass the contents (from octet 3 up to the last octet) of radio interface messages 
from one network entity to another. 



8 


7 


6 ' 5 

1 


' 4 ' 3 ' 2 
1 1 1 


1 








Element 


identifier 




octet 1 


Length 


octet 2 






Layer 3 


message contents 




octet 3 - 


- n 



The length indicator (octet 2) is a binary number indicating the absolute length of the contents after the length indicator 
octet. 

Octet j (j = 3, 4, ..., n) is the unchanged octet j of a radio interface layer 3 message as defined in GSM 04.08, n is equal to 
the length of that radio interface layer 3 message. 



3.2.2.36 



Channel Needed 



This information element contains an indication for the mobile station of which channel is needed for the transaction 
linked to the paging procedure. 

It is coded as follows: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Spare 


Channel 


octet 2 
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Bit 



21 

00 
01 
10 

1 1 



Any channel 

SDCCH 

TCH/F (Full rate) 

TCH/H or TCH/F (Dual rate) 



3.2.2.37 Trace Type 

A fixed length element indicating the type of trace information to be recorded. 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Trace type 


octet 2 



Octet 2 contains the trace type. 

Octet 2 is coded as the MSC/BSS Trace Type specified in GSM 12.08. 

3.2.2.38 TriggerlD 

A variable length element indicating the identity of the entity which initiated the trace. 



8 


7 


6 ' 5 ' 4 ' 3 
1 1 1 


2 


1 




Element identifier 


octet 1 


Length 


octet 2 


Entity identity 


octets 3-22 



Octets 3-22 may be typically an OMC identity. 

3.2.2.39 Trace Reference 

A fixed length element providing a trace reference number allocated by the triggering entity 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


TraceRef erence 


octet 2-3 



3.2.2.40 TransactionID 

A potentially variable length element indicating a particular transaction within a trace. 



8 


7 


6 ' 5 ' 4 ' 3 
1 1 1 


2 


1 




Element identifier 


octet 1 


Length 


octet 2 


Transaction number 


octet 3-4 
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8 


7 


6 ' 5 ' 4 ' 3 
1 1 1 


2 


1 




Element identifier 


octet 1 


Length 


octet 2 


Mobile identity 


octet 3-n 



Octet 3-n contain either the IMSI, IMEISV or IMEI as coded in GSM 04.08, not including GSM 04.08 element identifier 
or GSM 04.08 octet length value. 

3.2.2.42 OMCID 

A variable length element indicating the destination OMC to which trace information is to be sent. 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Length 


octet 2 


OMC identity 


octets 3-22 



For the OMC identity, see TS 12.20 

3.2.2.43 Forward Indicator 

A fixed length element indicating whether the trace is to be continued in a BSS to which the call has been handed over. 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


spare 


Forward indicator 


octet 2 



Octet 2 is coded as follows: 



bit 



4321 
0001 
0010 



forward to subsequent BSS, no trace at MSC 
forward to subsequent BSS, and trace at MSC 



All other values are reserved. 
Bits 5-8 are spare. 

3.2.2.44 Chosen Encryption Algorithm 

This element indicates the encryption algorithm being used by the BSS. 
It is coded as follows: 



8 


7 


6 ' 5 ' 4 ' 3 ' 
1 1 1 1 


2 


1 




Element identifier 


octet 1 


Algorithm identifier 


octet 2 



The algorithm identifier caters for the possible future introduction of different user data encryption algorithms. It is coded 

as; 



ETSI 



GSM 08.08 version 6.2.0 Release 1997 



100 



TS 100 590 V6.2.0 (1998-11) 



0000 000 1 No encryption used 

0000 0010 GSM user data encryption version 1(A5/1). 

0000 0011 GSMA5/2 

0000 0100 GSM A5/3 

0000 0101 GSM ASM 

0000 0110 GSMA5/5 

0000 0111 GSMA5/6 

0000 1000 GSMA5/7 

All other values are Reserved for future international use. 

3.2.2.45 Circuit Pool 

This element indicates the circuit pool of a circuit or group of circuits. 
It is coded as follows; 



8 


7 


6 ' 5 ' 4 ' 3 ' 

ill! 


2 


1 




Element identifier 


octet 1 


Circuit pool number 


octet 2 



Predefined circuit pools are currently Circuit pool number 1 to Circuit pool number 22. 

The circuit pool element is coded as follows (along with the definition of the predefined circuit pools): 



Coding 


Pool 


Supported channels and speech coding algorithms 


0000 0001 


Circuit pool number 1 


FR speech version 1 
FRdata(12, 6, 3.6 kbit/s) 


0000 0010 


Circuit pool number 2 


HR speech version 1 
HR data (6, 3.6 kbit/s) 


0000 0011 


Circuit pool number 3 


FR speech version 1 
FRdata(12, 6, 3.6 kbit/s) 
HR speech 
HR data (6, 3.6 kbit/s) 


0000 0100 


Circuit pool number 4 


FR speech version 2 
FRdata(12, 6, 3.6 kbit/s) 


0000 0101 


Circuit pool number 5 


FR speech version 1 
FR speech version 2 
FRdata(12, 6, 3.6 kbit/s) 


0000 0110 


Circuit pool number 6 


FR speech version 2 
FRdata(12, 6, 3.6 kbit/s) 
HR speech version 1 
HR data (6, 3.6 kbit/s) 


0000 0111 


Circuit pool number 7 


FR speech version 1 
FR speech version 2 
FRdata(12, 6, 3.6 kbit/s) 
HR speech version 1 
HR data (6, 3.6 kbit/s) 


0000 1000 


Circuit pool number 8 


HSCSD max 2 x FR data (12, 6 kbit/s) 


0000 1001 


Circuit pool number 9 


FRdata(12, 6, 3.6 kbit/s) 

HR data (6, 3.6 kbit/s) 

HSCSD max 2 x FR data (12, 6 kbit/s) 


0000 1010 


Circuit pool number 10 


FR speech version 1 

FR speech version 2 

FRdata(12, 6, 3.6 kbit/s) 

HR speech version 1 

HR data (6, 3.6 kbit/s) 

HSCSD max 2 x FR data (12, 6 kbit/s) 


0000 1011 


Circuit pool number 11 


HSCSD max 4 x FR data (12, 6 kbit/s) 






(continued) 
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(concluded): 



Coding 


Pool 


Supported channels and speech coding algorithms 


0000 1100 


Circuit pool number 12 


FRdata(12, 6,3.6 kbit/s) 

HRdata(6, 3.6kbit/s) 

HSCSD max 4 x FR data (12, 6 kbit/s) 


0000 1101 


Circuit pool number 13 


FR speech version 1 

FR speech version 2 

FRdata(12, 6, 3.6 kbit/s) 

HR speech version 1 

HR data (6, 3.6 kbit/s) 

HSCSD max 4 x FR data (12, 6 kbit/s) 


0000 1110 


Circuit pool number 14 


HSCSD max 6 x FR data (12, 6 kbit/s) 


0000 1111 


Circuit pool number 15 


FR data (14.5 kbit/s) 


0001 0000 


Circuit pool number 16 


HSCSD max 2 x FR data (14.5 kbit/s) 


0001 0001 


Circuit pool number 17 


HSCSD max 4 x FR data (14.5 kbit/s) 


0001 0010 


Circuit pool number 18 


FR data (14.5, 12, 6, 3.6 kbit/s) 

HR data (6, 3.6 kbit/s) 

HSCSD max 2 x FR data (1 4.5, 1 2, 6 kbit/s) 


0001 0011 


Circuit pool number 19 


FR data (14.5, 12, 6, 3.6 kbit/s) 

HR data (6, 3.6 kbit/s) 

HSCSD max 4 x FR data (14.5, 12, 6 kbit/s) 


0001 0100 


Circuit pool number 20 


FR speech version 1 

FR speech version 2 

FR data (14.5, 12, 6, 3.6 kbit/s) 

HR speech version 1 

HR data (6, 3.6 kbit/s) 


0001 0101 


Circuit pool number 21 


FR speech version 1 

FR speech version 2 

FR data (14.5, 12, 6, 3.6 kbit/s) 

HR speech version 1 

HR data (6, 3.6 kbit/s) 

HSCSD max 2 x FR data (14.5, 12, 6 kbit/s) 


0001 0110 


Circuit pool number 22 


FR speech version 1 

FR speech version 2 

FR data (14.5, 12, 6, 3.6 kbit/s) 

HR speech version 1 

HR data (6, 3.6 kbit/s) 

HSCSD max 4 x FR data (14.5, 12, 6 kbit/s) 








lOOOxxxx 


For national/local use 





3.2.2.46 Circuit Pool List 

This element defines alist of BSS preferred circuit pools in order of preference. 
It is coded as follows: 



1 

8 
1 


7 ' 6 ' 
1 1 


5 ' 4 ' 
1 1 


3 ' 2 ' 1 
1 1 






Element 


identifier 




octet 


1 


Length 


octet 


2 




Circuit 


pool number 


(1st preferred) 


octet 


3 




■ 




Circuit 


pool number 


(nth preferred) 


octet 


n+2 



The Circuit pool number is coded as specified in 3.2.2.45. 
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3.2.2.47 Time Indication 

This element defines the period where the information shall be valid. It is fixed length, 2 octets. 
The coding is as follows: 



8 


7 


6 


5 


4 


3 


2 


1 




Element identifier 


octet 1 


Time 


octet 2 



The Time field of this Information Element message in octet 2 is coded as follows; 
(note) 



0000 0000 
0000 0001 

nil 1110 



Time, 



where the time is the binary value of octet 2 * 10s (ie 10s to 2540s). 

If the Time field contains the value 255(1111 1111), the receiving entity shall consider the time as infinite. 
NOTE: The value has a special meaning in the Load indication procedure (refer to subclause 3.1.20). 



3.2.2.48 



Resource Situation 



This element gives, for respective indicated channel type, the total number of channels accessible and the number of 
channels available on any given cell at the time of construction of the message. 

The number of channels available may be defined in up to five interference bands, the boundaries of these bands being set 
by O and M as follows; 



Interference level: 







XI 



X2 



X3 



X4 



X5 



Band 1 


Band 2 


Band 3 


Band 4 


Band 5 



The element is coded as follows: 
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8 


7 


6 


5 


4 


3 


2 


1 




Element identifier 


octet 


1 


Lenqth 


octet 


2 


Resource and interference band 
indicator 


Channel type 


octet 


3 


7/15 
ind. 


Number of channels 


octet 


4 




octet 


4a 


Resource and interference band 
indicator 


Channel type 


octet 


5 


7/15 
ind. 


Number of channels 


octet 


6 




octet 


6a 



Resource and interference band 
indicator 


Channel type 


octet N-1 


7/15 
ind. 


Number of channels 


octet N 




octet Na 



The length indicator is a binary representation of the length of the following element. 

The Resource type octet (octets 3, 5, etc.) is coded as follows: 

The Channel type field (bits 1-4 of octets 3, 5, etc.) is coded as follows; 



Bit 



4321 

1 SDCCH 

10 Full Rate TCH 

100 1 Half Rate TCH 

All other values are reserved. 



The Resource and interference band indicator field (bits 5-8 of octets 3, 5, etc.) is coded as follows; 



Bit 



8765 

Total number of channels accessible (i.e. available for service or currently assigned) 

1 Number of channels available in interference band 1 

10 Number of channels available in interference band 2 

11 Number of channels available in interference band 3 

10 Number of channels available in interference band 4 

10 1 Number of channels available in interference band 5 

1110 Number of channels available without supplied interference band classification 

All other values are reserved. 



The Number of channels octets (octets 4, 6, etc.) is coded as follows; 

The Number of channels is a single octet element if the 7/15 indication bit (bit 8 of octets 4, 6, etc.) is set to 0. If the 7/15 
indication bit is set to 1 then it is a 2 octet field. It give a 7 (or 15) bit binary representation of the number of channels 
with resource type as indicated in the nearest preceding resource type octet. The coding convention used when a field 
extends over more than one octet is defined in subclause 3.2.2. 

The number of half rate channels will include half rate channels counted as full rate channels, if these correspond to full 
rate channels that can be used as half rate channels. 

(e.g. If there is one idle half rate channel and one idle full rate channel that can be used as two half rate channels, then the 
full rate count will be 1 and the half rate count will be 3). 

The Resource type octet and the Number of channels octet(s) are repeated for each of the resource type reported. 

For each of the channel type reported, the total number of channels accessible and at least one indication of available 
channels shall be included. 
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The number of channels available without supplied interference band classification is included only in case the 
interference band definition is not available for the reported channel type. 

3.2.2.49 Current Channel Type 1 

This Information Element contains a description of the channel allocated to the MS. 
It is coded as follows: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


Channel mode 


Channel 


octet 2 



The channel mode field is coded as follows: 

Bit 8765 

0000 signalling only 

0001 speech (full rate or half rate) 

01 10 data, 14.5 kbit/s radio interface rate 

001 1 data, 12.0 kbit/s radio interface rate 

0100 data, 6.0 kbit/s radio interface rate 

0101 data, 3.6 kbit/s radio interface rate 
1111 is reserved 

All other values are for future use. If the receiver receives an unknown channel mode it shall not be rejected but the 
receiver shall assume that the channel mode is to be changed. 

The channel field is coded as follows: 



Bit 



4321 

0001 SDCCH 

1000 1 Full rate TCH 

1001 1 Half rate TCH 

1010 2 Full Rate TCHs 

1011 3 Full Rate TCHs 

1100 4 Full Rate TCHs 

1101 5 Full Rate TCHs 
1110 6 Full Rate TCHs 
nil 7 Full Rate TCHs 
0100 8 Full Rate TCHs 
0000 is reserved 



All other values are for future use. If the receiver receives a unknown channel field it shall not be rejected but the receiver 
shall assume that the channel is to be changed. 

Consistencies between channel fields and channel modes shall not be checked. 

3.2.2.50 Queuing Indicator 

This element contains a recommendation of the BSS concerrung application of queuing. 
The element has a fixed length of two octets. 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


spare 


qri 


spare 


octet 2 



Octet 2 is coded as follows: 
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qri = queuing recommendation indicator 




1 



it is recommended not to allow queueing 
it is recommended to allow queueing 



3.2.2.51 Speech Version 

This element indicates the speech version being used by the BSS. 
It is coded as follows: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


spare 


Speech version identifier 


octet 2 



The bits 7-1 of octet 2 are coded in the same way as the permitted speech version identifier in the Channel type 
information element. 

3.2.2.52 Assignment Requirement 



8 


7 


6,5,4,3 


2 ' 1 




Element identifier 


octet 1 


Assignment requirement 


octet 2 



Octet 2 

00000000 Delayed 

00000001 Immediate 
all other values are reserved 

3.2.2.53 [spare] 

3.2.2.54 Talker Flag 



8 


7 


6 


5 4 


3 


2 


1 




Element identifier 


octet 1 



3.2.2.55 Group Call Reference 

It is coded as follows: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 
1 1 1 1 1 1 


2 ' 1 
1 




Element identifier 


octet 1 


Length 


octet 2 


Descriptive group or broadcast call 


reference 


octets 3-7 



Octet 2 is a binary indication of the length of the remainder of the element in octets. 

The octets 3 to 8 are coded in the same way as the octets 2-6 in the Descriptive group or broadcast call reference 
information element as defined in GSM 04.08. 
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3.2.2.56 eMLPP Priority 

This Information Element contains the eMLPP priority of the call. 
It is coded as follows: 



8 ' 7 ' 6 ' 5 ' 4 ' 3 ' 2 ' 1 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


spare 


call priority 


octet 2 



The call priority field (bit 3 to 1 of octet 2) is coded in the same way as the call priority field (bit 3 to 1 of octet 5) in the 
Descriptive group or broadcast call reference information element as defined in GSM 04.08. 



3.2.2.57 Configuration Evolution Indication 

This information element indicates whether subsequent assignment requests should be expected and the limitation for these 
subsequent assignments. 



8 


7 6 


5 4 


3 2 


1 




Element identifier 


octet 1 




spare 




SMI 




octet 2 



SMI: Subsequent Modification Indication. This indicates the maximum number of TCH/F that could be requested in 
subsequent assignments. 

The SMI field is coded as follows: 



Bit 



4321 

0000 No Modification is allowed 

0001 Modification is allowed and maximum number of TCH/F is 1 

0010 Modification is allowed and maximum number of TCH/F is 2 

001 1 Modification is allowed and maximum number of TCH/F is 3 
0100 Modification is allowed and maximum number of TCH/F is 4 



All other values are reserved. 

3.2.2.58 Old BSS to New BSS information 

This information element is defined as a general container for passing Field Elements transparently between BSSs via the 
MSC. 

These Field Elements are passed in the "Old BSS to New BSS information elements" octets field. The error handling 
performed by the receiving entity for the "Old BSS to New BSS information elements" field is that specified in section 
3.1.19.7. 



8 


7 


6 5 4 3 2 


1 


















Element identifier 




octet 1 
















Length 




octet 2 












Old 


BSS to 


New BSS information elements 




j octet 3-n 



The length indicator (octet 2) is a binary number indicating the absolute length of the contents after the length indicator 
octet and may be set to zero. 

The Old BSS to New BSS information elements field is made up of or more Field Elements listed in the table shown 
below. 

Field elements may occur in any order in the Old BSS to New BSS information elements field. 

The construction of the Field Elements allows the receiver to ignore unknown Field Elements. 
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Due to backward compatibility issues Field Elements in the "Old BSS to New BSS information" may duplicate 
Information Elements in the HANDOVER REQUEST, when this occurs and the new BSS detects an inconsistency 
between this information then the information contained in the "Old BSS to New BSS information" shall take precedence 
as long as the coding is understood by the new BSS. 

Reception of an erroneous "Old BSS to New BSS information" shall not cause a rejection of the HANDOVER REQUEST 
message; the "Old BSS to New BSS information" information element shall be discarded and the handover resource 
allocation procedure shall continue. 



FIELD ELEMENT 


REFERENCE 


LEN 


Extra information 
Current Cliannel Type 2 
Target cell radio information 
GPRS Suspend information 


3.2.3.1 
3.2.3.2 
3.2.3.3 
3.2.3.4 


3 
4 
3 
19 



3.2.3 SIGNALING FIELD ELEMENT CODING 

The coding rules for signalling field elements are the same as the signalling element coding rules which are defined in 
section 3.2.2. 

Signalling field elements shall always include a Field Length indicator. A Field Length indicator with a value of zero 
shall not be considered as an error. 



Field 






Element 


Field Element name 


Reference 


Identifier 






Coding 






0000 0001 


Extra information 


3.2.3.1 


0000 0010 


Current Channel Type 2 


3.2.2.2 


0000 0011 


Target cell radio information 


3.2.3.3 


0000 0100 


GPRS Suspend information 


3.2.3.4 



All other values are for future use. 

3.2.3.1 Extra information 

This field element provides a general flag mechanism that allows the old BSS to indicate to the new BSS flag information. 
It is coded as follows: 



8 


1 1 

7 6 5 
1 1 


1 1 

4 3 
1 1 


2 


1 






Field Element 


identifier 






octet 1 


Length 


octet 2 




octet 3 



Octet 2 is a binary indication of the length of the rest of the field element. 
Octet 3 is coded as follows: 



1 1 1 1 1 1 1 

8 7|6 5 4 3 2 1 
1 1 1 1 1 




ill 

spare 
1 1 1 


prec 


octet 3 



Bit 8 to 2 are flags that indicate no information, 
prec = Pre-emption Recommendation 
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1 



The old BSS recommends that this allocation request should not cause a pre-emption an existing 

connection. 

The old BSS recommends that this allocation request is allowed to preempt an existing connection 

based on the information supplied in the Priority information element, if available. 



In the case the "prec" bit is not present or the Extra Information field element is not present then the new BSS should run 

pre-emption as specified by the Priority information element, if available. 

In the case where the Priority information element is not present in the request then the "prec" element, if present, shall be 

ignored. 

3.2.3.2 Current Channel type 2 

This Field Element contains a description of the channel allocated to the MS. 
It is coded as follows: 



1 1 1 1 1 1 1 

87654321 
1 1 1 1 1 1 1 




Element identifier 


octet 


1 


1 

Length 


octet 


2 


1 

Channel mode 


octet 


3 


1 

Channel field 
1 


octet 


4 



The channel mode field is coded as follows: 

Bit 4321 

0000 signalling only 

0001 speech (full rate or half rate) 

01 10 data, 14.5 kbit/s radio interface rate 

001 1 data, 12.0 kbit/s radio interface rate 

0100 data, 6.0 kbit/s radio interface rate 

0101 data, 3.6 kbit/s radio interface rate 
1111 is reserved 

All other values indicate that no information is provided. 

Bits 8 to 5 are spare. 

The channel field is coded as follows: 

Bit 4321 

0001 SDCCH 

1000 1 Full rate TCH 

1001 1 Half rate TCH 

1010 2 Full Rate TCHs 

1011 3 Full Rate TCHs 

1100 4 Full Rate TCHs 

1101 5 Full Rate TCHs 
1110 6 Full Rate TCHs 
nil 7 Full Rate TCHs 
0100 8 Full Rate TCHs 
0000 is reserved 

All other values indicate that no information is provided. 
Bits 8 to 5 are spare. 



3.2.3.3 



Target cell radio information 



It is coded as follows: 
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8 


7 


1 

6 5 
1 


1 1 

4 3 
1 1 


2 


1 








Element 


identifier 






octet 1 


Length 


octet 2 




octet 3 



Octet 2 is a binary indication of the length of the rest of the element. 
Octet 3 is coded as follows: 



T r 

7 I 



T r 

5 
J L 



T 1 1 r 

3 2 1 



RXLEV-NCELL 
I 



octet 3 



Bit 8 to 6 is spare, set to 

Bit 5 to 1 is the RXLEV-NCELL field. 

The RXLEV-NCELL field is coded as the binary representation of a value N. N corresponds according to the mapping 
defined in TS. GSM 05.08 to the received signal strength on the target cell. 

3.2.3.4 GPRS Suspend Information 

This Field Element contains the contents of the Gb interface SUSPEND ACK PDU. 
It is coded as follows: 



1 1 1 1 1 1 1 

87654321 
1 1 1 1 1 1 1 




Element identifier 


octet 1 


1 

Length 


octet 2 


1 

Gb interface TLLI lEI 


octet 3 


1 

Length of TLLI 


octet 4 


1 

TLLI 


Oct 5 - 5+m 


1 

Gb interface RAI lEI 


octet 6+m 


1 

Length of RAI 


octet 7+m 


1 

RAI 


Oct 7+m - n 


1 

Gb interface SRN lEI 


octet n+1 


1 

Length of SRN 


octet n+2 


1 

Suspend reference number 
1 


Oct n+3 -p 



The coding of the fields are not relevant to GSM 08.08 
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3.2.4 List of Timers in tine BSSMAP Procedures 



Timer 


Title 


Time 


T1 


Time to receipt of BLOCKING ACKNOWLEDGE.at the BSS 


O&M 


T2 


Reset guard period at tlie MSG 


O&M 


T4 


Time to receipt of RESET ACKNOWLEDGE at the BSS 


O&M 


T5 


Overload timer in the IVISC, see 3.1.12.1 


O&M 


T6 


Overload timer in the IVISC, see 3.1.12.1 


O&M 


T7 


Handover required periodicity 


O&M 


T8 


Time to receipt of successful handover information 


O&M 


TIG 


Time to return of ASSIGNMENT COMPLETE or ASSIGNMENT FAILURE 






from MS (note) 


O&M 


Til 


Maximum allowed queuing time for assignment 


O&M 


T12 


Time to receipt of RESET CIRCUIT ACKNOWLEDGE at the MSC 


O&M 


T13 


Reset guard period at the BSS 


O&M 


T16 


Time to receipt of RESET ACKNOWLEDGE at the MSC 


O&M 


T17 


Overload timer in the BSS, see 3.1.12.1 


O&M 


T18 


Overload timer in the BSS, see 3.1.12.1 


O&M 


T19 


Time to receipt of RESET CIRCUIT ACKNOWLEDGE at the BSS 


O&M 


T20 


Time to receipt of CIRCUIT GROUP BLOCKING ACKNOWLEDGE at the BSS.. 


O&M 


T21 


Time to receipt of BLOCKING ACKNOWLEDGE at the MSC 


O&M 


T22 


Time to receipt of CIRCUIT GROUP BLOCKING ACKNOWLEDGE at the MSC 


O&M 


Tqho 


Maximum allowed queuing time for handover 


O&M 



NOTE: TIO is not the same as T3 107 as defined in GSM 04.08 

3.3 SDL Representation Of The Procedures At The BSS 

The SDL diagrams may be inserted at a later stage after updating and carefully checking of consistency with the main text. 

4 Broadcast Information Control Channel 

Information that is transferred in the Broadcast Control Channel is stored locally at the BSS. The scheduling of this 
information on the BCCH is controlled autonomously by the BSS. 

The set of information that is transmitted in the BCCH is derived locally or downloaded to the BSS via the BSS Operation 
and Maintenance Application Part. 

5 Vocabulary 

This clause contains definition of terms: 

BSS 

Base Station System. This is the equipment which is accessed through the interface defined in the 08-series of Technical 
Specifications. It contains the functionality described in GSM 08.02, and supports one or more cells. See GSM 01.04. 

BSSAP 

The Base Station System Application Part, this is the subsystem that contains the process dealing with radio resource 
control and management known as the Base Station System Management Application Part (BSSMAP) and transparent 
transfer of call control and mobility management information known as the Direct Transfer Application Part (DTAP). The 
BSSAPs at the BSS and the MSC are connected by means of SCCP connections. 

DTAP 

The DTAP, Direct Transfer Application Part is a process which allows the direct transfer of messages between 
individual MSs and the MSC with no interpretation of layer 3 information at the BSS. 
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BSSMAP 

Base Station System Management Application Part. This is the process within the BSS that controls radio resources in 
response to instructions from the MSC. 

INTERNAL HANDOVER 

An internal handover is a handover which takes place between channels on a cell or cells controlled by a single BSS. 
This handover operates without reference to the MSC (although the MSC will be informed on completion). Handovers of 
this type in one cell are called internal intra cell handovers and between cells are called internal inter cell handovers. 

Handovers between channels on the same cell or between cells on the same BSS which are controlled by the MSC are 
external handovers and use identical procedures to those for inter-BSS handovers. 

DIRECTED RETRY 

Directed Retry is the process of assigning a Mobile Station to a TCH in a cell other than the serving cell, e.g. in situations 
of congestion. It is triggered by the assignment procedure and employs internal or external handover procedures. 

VGCSA'BS 

VGCSA^BS call controlling SCCP connection: The VGCSA^BS call controUing SCCP connection is an SCCP 
connection which supports the signalling for call SETUP of a VGCS/VBS call. One of these connections is needed to 
support each instance of a VGCSA^BS call within a BSS. 

VGCSA^BS resource controlling SCCP connection: The VGCS/VBS resource controUing SCCP connection is an 
SCCP connection which supports the allocation of resources for a VGCSA'BS call. One or more of these connections is 
needed to support each instance of a VGCSA^BS call. The eact number of these SCCP connections is equal to the number 
of cells to which the VGCSA^BS call is to be supported. 



List of diagrams 



Figure 


Title 


1. 


Signalling protocol reference model 


2. 


Assignment 


3. 


Handover execution 


4. 


Handover required indication 


5. 


Handover resource allocation 


6. 


Release 


7. 


Release due to reason at the BSS 


8. [not used] 




9. 


Classmark updating 


10. 


Blocking of terrestrial circuits 


11. 


Reset 


12. 


Resource indication 


13. 


Handover candidate enquiry 


14. 


Flow control 


15. 


Paging 


16. 


Overview of handover procedure between two BSS's on the same IVISC 


17. 


Cipher mode control 


18. 


SARI "n" rejection 


19. 


Load indication 


20 


SUCCESSFUL UPLINK ALLOCATION 


21 


UNSUCCESSFUL UPLINK ALLOCATION 


22 


UPLINK RELEASE INDICATION 


23 


UPLINK SEIZE COMMAND 


24 


UPLINK RELEASE COMMAND 


25 


Blocking of terrestrial circuits, MSC initiated 


26 


Circuit re-selection 
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A-INTERFACE 



To Other processes 
within the BSS 



To air 
interface 
transmission 
equipment 



3SSAP 



BSS 

MAP 



Distribution 
Function 



BSS 
OMAP 



S C C P 



M T P 



PHYSICAL 



MSC-SIDE 



To Other 

applications 

eg. call control 



BSSAP 



BSS 
MAP 



Distribution 
Function 



S C C P 



M T P 



LAYER 



Terminology: 



Direct Transfer Application Part 
BSS Management Application Part 



DTAP 

BSSMAP 

BSS OMAP - BSS Operation and Maintenance Application Part 

SCCP ..... 

MTP 
BSS 
MSC 



- Signalling Connection and Control Part 

- Message Transfer Part 

- Base Station System 

- Mobile services Switching Centre 



NOTE: X.25 can be used for transferring and M information 



Operation and 
Maintenance 
information 
to PLMN 
O&M centre 



BSS 
OMAP 



SCCP 



MTP 



To Other 
users of 
SCCP and 

MTP 



Figure 1 : SIGNALLING PROTOCOL REFERENCE MODEL 
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MS 



MS 



ASSIGNMENT 



BSS 



ASSIGNMENT 
COMMAND 



ASSIGNMENT 
COMPLETE 



ASSIGNMENT 

REQUEST 

< 



ASSIGNMENT 
COMPLETE 



FIG 2 
HANDOVER EXECUTION 
BSS 



HANDOVER 
COMMAND 



HANDOVER 
COMMAND 



<- 



MSC 



MSC 



note 



CLEAR COMMAND 



FIG 3 
NOTE: A timer T8 is started to protect the overall procedure 
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MS 
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FIG 4 
HANDOVER RESOURCE ALLOCATION 

BSS MSC 



(HANDOVER 
COMPLETE) 



HANDOVER 
REQUEST 



HANDOVER 
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HANDOVER 
COMPLETE 



NOTE: 



note 



FIG 5 

The instant of generation of the Handover Complete is described in the 
text of Technical Specification GSM 08.08 
RELEASE 
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FIG 6 
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RELASE DUE TO REASON AT THE BSS 
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FIG 7 

CLASSMARK UPDATING 
BSS 



MSC 
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CHANGE 
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FIG 9 

BLOCKING OF TERRESTRIAL CIRCUITS 

MS BSS MSC 

BLOCK 
> 



BLOCK ACK 



UNBLOCK 



UNBLOCK ACK 



FIG 10 
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MS 



RESET 
BSS 



MSC 
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RESET 



<- 



RESET ACK 



RESET 



T2 



RESET ACK 



MS 



FIG 11 
RESOURCE INDICATION 
BSS 



RESOURCE 
REQUEST 



MSC 



RESOURCE 
INDICATION 



RESOURCE 
INDICATION 



MS 



FIG 12 
HANDOVER CANDIDATE ENQUIRY 

BSS 

HANDOVER 

CANDIDATE 

ENQUIRY 



MSC 



note — 



HANDOVER REQUIRED 
> 



HANDOVER REQUIRED 
> 



HANDOVER REQUIRED 



-> 



HANDOVER 

CANDIDATE 

RESPONSE 



FIG 13 

NOTE: Receipt of the Handover Candidate Enquiry Message causes the generation 

of a Handover Required message for each of candidate MS. These are sent as 

connection oriented messages. When all Handover Required messages have been 

generated a global Handover Candidate Response message is returned. 
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FIG 14 
PAGING 

BSS 



MSC 



PAGING 
REQUEST 
TYPE 1, 2, 



PAGING 
REQUEST 
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PAGING 



PAGING 



MS 



FIG 15 

OVERVIEW OF THE HANDOVER PROCEDURE BETWEEN TWO BSS ' S ON THE SAME MSC . 

BSS MSC BSS MS 
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FIG 16 



NOTE: The Handover Complete message can be sent as soon as the BSS is certain that the MS has 

successfully been captured. 
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FIG 17 
SAPI "n" REJECTION 
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FIG 18 
The BSS or MS is not equipped for the SAPI request. 
LOAD INDICATION 
BSS MSC BSS 
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FIG 19 
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FIG 20 
UNSUCCESSFUL UPLINK ALLOCATION 
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FIG 21 
UPLINK RELEASE INDICATION 
MS BSS 
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FIG 22 
UPLINK SEIZE COMMAND 
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FIG 23 
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